spud beasts

[Olly Betts]

In message <02ce01c031dc$bf26c890$0a3c10ac@gordon>, "Julian Todd" writes:
>First it was all going to be so general that you wouldn't know 
>what the content was.

Eh?  The only things remotely like this is this:

  My plan is to store the survey data in a structured file format (possibly
  an XML-like packed binary structure)

All this is saying is that I expect the format to be more structured than
.svx files are.  Most of your complaints about .svx files boil down to a
lack of structure, so I'm suprised you aren't in favour of this.

>And now you are talking about 
>defining specific structures for the tiny amounts of data.  

Only Phil has talked about that so far.

>The fact is it doesn't matter what form the data is stored in at all.

I'm not concerned with how the data is stored at present - I'm thinking
about the internal structures, i.e. those stored in memory and used for
processing the data.  The survex 1 structures would be hard to extend to do
some of the things I'd like to be able to do, and they also aren't very
encapsulated - bits of network code have to be very aware of what other bits
do, which makes changes error prone.

>Whenever I have gotten hold of a cave data file 
>in another format (Walls and Toporobot so far) I have been 
>able to upgrade Tunnel to read it in half a days work.  

Exactly - that's why I believe we can sidestep the whole exchange format
minefield and allow people to write input filters to directly read data in
alien formats.  Reading data in a format is rather easier than translating
it to a natural representation in another format.

>Why don't you consider sticking with the survex format 
>and making the improvements to it I have outlined 
>many times before (*exports, labels on the *calibrates, 
>abolition of *include, *begin/*end, *equate and *units) ?  

Those changes are so major that in reality you've got a new format.  It
might have a ".svx" extension, but it couldn't be read by Survex 1.0, and
Survex 1.0 files couldn't be read by it.  Possibly Survex 1.0 could be
patched to read it, and a conversion utility written for all the existing
data, but the same applies to any new format.

>All you are going to do is produce another data format 
>with horrible flaws in it, in the same way survex had originally 

And your god-like prescience of course means your adapted .svx format is
perfect?  In fact, you're arguing it's better because it learns from
problems with the original format, but so can any new format.

>So what, exactly, do you need another file type for?  Hmm?  
>[Hint: you have to name a particular feature you can't 
>have already now to make a justification]

Your adapted format is really a new file format, so Julian, why DO we need
it?  What features does it add?

>PS What's wrong with Java apart from it's easy to write 
>and you don't need to be a professional GTK programmer 
>to do it?  

I don't want to get into language wars.  The bottom line is I don't want to
write in Java, and neither does Mark or Phil.  This is a volunteer project,
so the people doing the work get to choose.

Cheers,
Olly