Subj : proposed new nodelist
To : mark lewis
From : Jasen Betts
Date : Thu Jul 18 2002 01:08 am
Hi mark.
15-Jul-02 18:33:20, mark lewis wrote to Jasen Betts
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 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>
once you go ro 5NF every filed is optional or may be repeated any numbrer
of times (except the key field)...
ml>>> i don't believe that we should add any more info to the current
ml>>> database style other than what is absolutely necessary...
JB>> information part of the style ?
ml> not sure of the reference... i was thinking of keeping the POTS
ml> data the same and building from there..
why keep pots?
JB>> what is necessary is something that'll work next year and keep
JB>> working without a major overhaul (one that obsoletes software
JB>> etc) a list of anonymous commas doesn't do that.
ml> my proposal do that with the requirement that someone still
ml> generate a SLF nodelist for those nodes that require the SLF
ml> nodelist..
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?
that's what I was proposing :)
ml> heck, we could code some sort of comma-encoding to
ml> show number of empty comma fields is that is a problem..
I'd prefer to make them optional.
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)..
yeah... I wonder if that would work, maybe the sendiing mailer would refuse
to send the packets if it didn'r see an AKA from the anwering mailer that
matcheds the address on the packets (you can see ther's a lot I don't know)
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..
yeah... I guess you can use the flags to determine what sort of
connection the line is describing, I was thinking of describing it
explicitly with a new field
There remains the question of system flags (flags that arent capability
flags like " NEC ") do they go on all lines or are they autmatically
duplicated somehow.
JB>> different connection methods have different information
JB>> requirements for dialup there's a phone number and a list of
JB>> modem protocols and mailer capabilities, for interent there's an
JB>> address (FQDN or IP) and a port number, and again mailer
JB>> capabilities, a field with the bitrate may be handy too, for
JB>> email attach I'm not sure what flags are needed, here bitrate is
JB>> less critical, but maximum size may be useful.
ml> true and that is easily handled in two of the storage formats i've
ml> tossed out..
JB>> if someone sets up fido via SMTP (a variation of via email?) or
JB>> even via snail-mail they'll probably need still different
JB>> fields...
JB>> we can design this thing so that the politicians can't control
JB>> it. so that new fields can be added without kludging them into
JB>> flags
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 :)
<<<GGG>>>> believe it or not, i know some systems that used to get
<<<GGG>>>> their fidofix
ml> via snailmailed tapebackups..
I've heard you can get usenet on cd-rom. didn't know fido was moved that way
too.
ml> )\/(ark
-=> Bye <=-
---
# Origin: I like work... I can sit and watch it for hours. (3:640/531.42)
* Origin: Baddog BBS (1:218/903)
