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 < 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 <=- --- # Origin: I like work... I can sit and watch it for hours. (3:640/531.42) * Origin: Baddog BBS (1:218/903) .