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

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

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

 ml> in any case, i do see the "bottom of the stack" of what you are
 ml> looking at... being able to list each method for one address and
 ml> thus not having to have multiple addresses and the added
 ml> complexity that that brings with it... i'm also not eliminating
 ml> multiple address capabilities because they are still necessary...
 ml> even if only for administrative addresses..

Yeah sure administrative addresses simplify setup... make it easier to
contact the NC etc...

But picking an an address to best match your contact capabilites at the
time you write the mail is needless complexity.

Maybe we should allow a range, or list in the nodenumber field so that the
conversion to SLF can spit out multiple lines where needed, but it seems to
me that most users will only need one connmection to any system - the one
that best matches their capabilities, the others just get in the way (for
them). But, yeah, keep the admistrative addresses they are a good thing
(tm)

 ml>>> with one empty field where all the IP stuff would be... an IP
 ml>>> only, continous mail, mail only system would look like..

 ml>>> of course, a system with no POTS or IP or userflags would simply
 ml>>> be...

 ml>>> ,12,Waldo's_Place_USA,Sanford_NC,Mark_Lewis,-,,-,,-,,

 ml>>> -=%*)

 JB>> no PVT flag ? (i guess it's not really needed)

 ml> exactly >

 ml>>> the first problem i see is one of line length unless we also
 ml>>> implement something like the above //wrapped style..

 JB>> yeah, definately, why not make it the law: how about this
 JB>> instead.

 JB>> any reason why the userflags can't follow the identity line.

 ml> not that i can see... i just chose an arbitrary layout after
 ml> seperating the data into the basic "chunks"..

 DM>>>> However, the standard could be written so that software
 DM>>>> developers know the direction we're headed and nodes would know
 DM>>>> what future upgrades might be necessary.

 ml>>> i'm sure the developers will already know what direction folks
 ml>>> want to head off in long before any work on documenting anything
 ml>>> gets started >

 JB>> too true :(

 ml> yeah... and i was right, too... folks are heading to the 'net and
 ml> the developers, too... and nothing has even come close to being as
 ml> fully documented as it should be..

 ml>>> maybe i should go ahead and document what i've just proposed and
 ml>>> present it to some mailer developers for feedback and
 ml>>> adjustment... then to the FTSC after the necessary nodelist
 ml>>> manipluation tools are in use... i see no difference in this and
 ml>>> the switch to the current St. Louis format back in '85... maybe
 ml>>> i'll call it the ESL nodelist format... ;-)

 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...

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

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

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

A test nodelist with some 120K long lines and other provocative data in it
might be worth distributing too.

 ml>>> we could do a multiline format... off the top of my head, maybe
 ml>>> something like this... again with the //wrappin

 JB>> back in 1980 comma delimeted lists were the last word in open
 JB>> data formats. these days we have better tools maybe some osrt of
 JB>> structured language would be more flexible?

 ml> i dunno... it is faster and easier to grab data from know
 ml> positions... as a coder, i want my code to run as fast as possible
 ml> without having to rely on the CPU speed to make it tolerable...

we only need to compile the nodelist once a week. as long as it takes less
than half a day to run it should be ok (just kidding)

that's a good point,

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

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

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

When it's time to actually use the data in the nodelist you're usually only
interested in a single destination and I think that even the slowest computer
could handle a tagged format in a reasonable amount of time.

however it could be an issue for the poor souls running 4mhz XTs _and_
needing to convert the nodelist to SLF but, if we get the format righ they
will be able to skip large blocks of fields as soon as the code can
determine that that block describes an unsuitable connection type for their
system.

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

 ml> yes, i still code with an eye on streamlined and i do still run
 ml> code optimizers so as to be able to streamline routines are are
 ml> often used and may be slow.

optimisation is good, but, 90% of the speed gains come from picking the
right agorithm, I've raced Qbasic (interpreted basic) against a commercial
compiled program and Qbasic won.

we need quick way to decide when a connection-block is useless and if it is
to fast-forward to the next one, counting commas would work if there was a
known number in each block...

 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 

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

 -=> Bye <=-

---