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

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

 JB> once you go ro 5NF every filed is optional or may be repeated
                 ^^^^^^
hunh???

 JB> any numbrer of times (except the key field)...

[trim]

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

 JB> why keep pots?

why eliminate existing technology? what would be done if something happened
to the internet and it collapsed? POTS will still be around for many years
to come...

[trim]

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

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

 ml>> understood but why? what is wrong with using a fixed format that
 ml>> is extensible?

 JB>  that's what I was proposing :)

that's confusing... a fixed format that has floating field positions...
seems more like an oxymoron...

 ml>> heck, we could code some sort of comma-encoding to
 ml>> show number of empty comma fields is that is a problem..

 JB> I'd prefer to make them optional.

then you loose the placeholders... they are needed if they are the first
row for that entry, too...

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

 JB> yeah... I wonder if that would work, maybe the sendiing mailer
 JB> would refuse to send the packets if it didn'r see an AKA from
 JB> the anwering mailer that matcheds the address on the packets
 JB> (you can see ther's a lot I don't know)

that's actually a normal part of fido mailer communications... the nodelist
doesn't even come into play at that point...

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

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

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

 JB> yeah... I guess you can use the flags to determine what sort
 JB> of connection the line is describing, I was thinking of
 JB> describing it explicitly with a new field

that's true... but i do rather kinda like my idea of adding a leading field
that contains the connection type that the row refers to... that would also
make it hugely easier to create oldstyle nodelist that contain just POTS
info or IP info only...

 JB> There remains the question of system flags (flags that arent
 JB> capability flags like " NEC ") do they go on all lines or are
 JB> they autmatically duplicated somehow.

automatically carried just like the rest of the data... its a "trickle
down" type flow... if there are 10 fields in the first row and the
second row only has data in fields 5 and 9 then those are the only two
fields changed in the row generated from the data in the first row...

[trim]

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

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

 JB> I've heard you can get usenet on cd-rom. didn't know fido
 JB> was moved that way too.

fidonet has been moved via many different methods... afterall, the only
goal is to get the PKTs from one system to another... HOW they move isn't
really that important unless it is via direct communications between the
originator and the destination... HAM/ShortWave radio, sneakernet, infrared
laser, fiberoptic, FM radio broadcast, snailmail, DAT tape, QIC tape, VHS
tape, morse code, and i'm sure that there are many other means...

)\/(ark