HK>>> A comma separated list is not very flexible, but instead
 HK>>> inherently quite rigid. A flexible format have to be built on
 HK>>> field identifiers, that is the only way to guarantee future
 HK>>> extentions without breaking existent next generation software.

 ml>> CSV databases have been used since the beginning of database
 ml>> information storage... yes, their format may be
"rigid" but that
 ml>> is the same for all database formats...

 JB> no it's not.  relational databases don't have such
 JB> limitations.

they do, however, have specific fields in the tables and that data is
stored in a specific place in the stream data... to me, relational
databases are just that... databases of data that is linked together via
some piece of info common in them... what folk see today as a table, i grew
up with knowing is as a database... making the switch from a database to
many linked via a piece of data between them was very easy for me...
another term would be database of databases >

 ml>> i don't believe that we should add any more info to the
 ml>> current database style other than what is absolutely
 ml>> necessary...

 JB> information part of the style ?

not sure of the reference... i was thinking of keeping the POTS data the
same and building from there...

 JB> what is necessary is something that'll work next year
 JB> and keep working without a major overhaul (one that
 JB> obsoletes software etc) a list of anonymous commas
 JB> doesn't do that.

my proposal do that with the requirement that someone still generate a SLF
nodelist for those nodes that require the SLF nodelist...

 ml>> why have to add field identifiers
 ml>> and then have to create "smart" programs that have to be
 ml>> able to pick out the data they need no matter what order
 ml>> it is in?

 JB> why not, it's not exaclty hard, if we're smart we'll be
 JB> able to co-opt some freeware SGML or XML (etc) parsing
 JB> library to the task (LGPL allows use if the library in
 JB> commercial code)

understood but why? what is wrong with using a fixed format that is
extensible? heck, we could code some sort of comma-encoding to show number
of empty comma fields is that is a problem...

sure, we could code up some relational database FDNS and import/update the
POTS data and have additional tables named for the functions served... POTS
table, FTP table, IBN table, etc... that database would be easily
extensible except for the fact that not all systems would have access and
not all future system may have access to the internet as we know it
today... it is, however, not much different from my proposal that we add
another field to the front of the SLF nodelist to designate that line's
use... it is then simply a matter of determining what subsequent lines will
contain and what it will mean... then is would be quite simple to simply
run thru and generate a SLF nodelist... GREP could surely do it and even
SED could be used to cut off the POTS id field... if a node is ION or has
some other connection method that keeps POTS and others from connecting
directly, some sort of placeholder will have to reside in the POTS SLF
nodelist for routing and such info (ie: some sort of gateway system)...

 ml>> it is
 ml>> much faster to read data directly from where you know it
 ml>> is to be rather than having to hunt it down... not only
 ml>> faster, but easier to code for, as well..

 JB> and so we have domain names in the BBS-name field or in
 JB> some flag... we can fix that tomorrow by adding more
 JB> commas but what happens when something new happens.

that's why i used blank commas... those fields use the existing data from
the last line read... only the data that needs to be changed is put in...
what that field is called doesn't really matter... it is the positioning
that is important in that format for the fastest reading and processing...

 JB> different connection methods have different information
 JB> requirements for dialup there,s a phone number and a
 JB> list of modem protocols and mailer capabilities,  for
 JB> interent there's an address (FQDN or IP) and a port
 JB> number, and again mailer capabilities, a field with the
 JB> bitrate may be handy too, for email attach I'm not sure
 JB> what flags are needed, here bitrate is less critical,
 JB> but maximum size may be useful.

true and that is easily handled in two of the storage formats i've tossed out...

 JB> if someone sets up fido via SMTP (a variation of via email?)
 JB> or even via snail-mail they'll probably need still different
 JB> fields...

 JB> we can design this thing so that the politicians can't
 JB> control it. so that new fields can be added without
 JB> kludging them into flags

 JB> I want to see a format that can handle any concievable
 JB> method of moving fido mail... even sneakernet. - disk
 JB> format(s), street address, contact name, room number,
 JB> hours etc :)

>> believe it or not, i know some systems that
used to get their fidofix via snailmailed tapebackups...

)\/(ark