Subj : proposed new nodelist
To : Jasen Betts
From : mark lewis
Date : Mon Jul 22 2002 08:45 pm
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 <<GG>
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> <<<GGG>>>> 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...
