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 

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 :)

 >>> believe it or not, i know some systems
that used to get
 >>> 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 <=-

---