JB> in the following I've used the acronym SLF for StLouis Format
 JB> (FTS 0005 or 500x)

 ml>> yeah, that was the original... however, with many folk still
 ml>> having and using older programming languages and compilers
 ml>> that do have specific line length limits, i don't know that
 ml>> it is really such a good format... and other things to
 ml>> consider, as well..

 JB> There is no such thing as a line length limit in any language
 JB> that can read binary files. (that means the 4 most popular ones
 JB> atleast)

true... but only as long as the programmer is willing to take the time to
code those needed routines if his chosen one doesn't support them
directly...

[trim]

 ml>>>> then again, i dunno... whatever we come up with must be
 ml>>>> extensible... the above will run into a linelength problem, i'm
 ml>>>> sure...

 JB>>> I think it's be better to document line length as unlimitted and
 JB>>> leave it to the developers to implement it. C compilers for
 JB>>> instance don't have any problems with line length (thst is, C
 JB>>> progams can have lines of any length.)

 ml>> my understanding is that they are limited (in older compilers) to
 ml>> 64k...

 JB> Only if they try to read the whole line into memory at the
 JB> same time. :)

exactly!

 ml>> yes, we could leave it to developers to implement it but
 ml>> then we are also hobbling wanna-be developers with good
 ml>> ideas and a mind and desire to code for us..

 JB> We've got some eager developers here... once we get the data
 JB> reading code working we'll document it and give it away and
 JB> developers get some known-good code that should well-enough
 JB> documented for them to use it instead of inventing their own
 JB> bugs...

that won't happen... there are many who want to "roll their own"
if they can... its happened with messagebase formats (HMB JAM SQUish) and
nodelist formats (FD's format, V7, GIGO's format, RA's format)... this
won't be any different, really...

[trim]

 JB> Actually to compile (index really, isn't it) the nodelist
 JB> you only need to read the fist two fields (initial flag,
 JB> and number) and record that and the file-position then
 JB> skip the rest of the data for that record an process the
 JB> next record (the next node)

no, some, like FD, actually create their own database from the data within
the distributed nodelist... there is actual data in nodelist fields that is
stored in the FD compiled nodelist "indices"...

 JB> So adding field tags to the variable fields would only
 JB> result in a slight slowdown (because of longer records
 JB> - so more disk activity and end-of-line seeking) at the
 JB> indexing stage.

 JB> Hmm, (since file position is so handy for the indexing
 JB> using a binary-capable language (mentioner earlier) makes
 JB> even more sense)

yup and i've also code to index an ASCII text file >

[trim]

 JB> here's a radical thpought - maybe the capability flags
 JB> (or the same information in a different format) should
 JB> go first to make it easier to skip useless connection
 JB> blocks.

sounds like my idea about adding another field to the start of the current
format... that field indicating the connection form (ie: POTS, IP, LEO,
INFRA, SMOKE) >

 ml>>>> POTS,Node,12,Waldo's_Place_USA,central_north_carolina_usa,//
 ml>>>> mark_lewis,1-919-774-5930,33600,CM,XA,V32b,V42b,H16,V32t,V34
 ml>>>> IP,,,bbs.wpusa.dynip.com,,,000-012-146-242,,CM,XA,ITN,IVM,IBN
 ml>>>> IP,,,,,,,,LO,MO,CM,XX,IBN

 JB>>> all those empty fields makes it hard to read, [...]

 ml>> just as in the current/original nodelist, its not designed for
 ml>> human consumption... it is a database... a flat ASCII textfile,
 ml>> CSV database... the editing program(s) know how many fields are
 ml>> supposed to be there 

 JB> So that means we need to write editors too.... have we got
 JB> any M$ windows programmers here? hmm maybe we need one
 JB> written in javascript ?

absolutely we need some sort of common editor to handle the new form... let
it do the work, you just fill in the blanks... however, we're looking at
what platforms, really, that this tool needs to operate on? anything truely
non-intel based? i'm thinking of a simple console based app that will run
on DOS, windows console or DOS box, OS/2 console or DOS box, and a linux
console... if the thing can be compiled on a linux box, it may verywell be
easily ported to other boxes like macs and commodore machines if older
machine like them are still available...

my thoughts on the IP based FDNS work around mySQL and PHP4...

)\/(ark