Subj : proposed new nodelist To : mark lewis From : Jasen Betts Date : Wed Jul 24 2002 01:32 pm Hi mark. ml>>> a piece of data between them was very easy for me... another ml>>> term would be database of databases < JB>> once you go ro 5NF every filed is optional or may be repeated ml> ^^^^^^ hunh??? JB>> any numbrer of times (except the key field)... To fifth normal form (might be fourth normal form), It's been a while since I studued that stuff... 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? ml> why eliminate existing technology? what would be done if something ml> happened to the internet and it collapsed? POTS will still be ml> around for many years to come.. What I meant was why keep pots in all the records when a large number of nodes don't use it. 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? why noty use the extensions to reduce size of the fixed component to the essentials. ml> then you loose the placeholders... they are needed if they are the ml> first row for that entry, too.. what I meant was by putting POTS into the extension there's no need for empty fields, on non-pots systems. ml> that's actually a normal part of fido mailer communications... That's good. ml> that's true... but i do rather kinda like my idea of adding a ml> leading field that contains the connection type that the row ml> refers to... that would also make it hugely easier to create ml> oldstyle nodelist that contain just POTS info or IP info only.. The type flag would make the softwar emuch easier to write, and yeah the program could probably be written fairly easily. 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. ml> automatically carried just like the rest of the data... its a ml> "trickle down" type flow... if there are 10 fields in the first ml> row and the second row only has data in fields 5 and 9 then those ml> are the only two fields changed in the row generated from the data ml> in the first row.. if is there's a flag on the first row that you don't want on the second row, what do you do... put it last on the fisrs row and use fewer commas on the second row? (could work but could trap many programmers) JB>>>> I want to see a format that can handle any concievable method JB>>>> of moving fido mail... even sneakernet. - disk format(s), JB>>>> street address, contact name, room number, hours etc :) ml>> <<>>> believe it or not, i know some systems that used to ml>> get their fidofix via snailmailed tapebackups.. My boss node just admitted that he carries echomail accross the room on a floppy disk, from his internet machine to the BBS. He's going on a motorbike trip so I the flow may bet a bit lumpy as Hell only b able to poll his uplink where He can find somewhere to plug his laptop in.. ml> fidonet has been moved via many different methods... ml> radio broadcast, snailmail, DAT tape, QIC tape, VHS tape, morse ml> code, and i'm sure that there are many other means.. Some jokers invented IP via carrier pidgeon, and it was tested and found to work, throughput wasn't real impressive though. if you're interested I'll try and dig up the RFC number. -=> Bye <=- --- # Origin: Every absurdity has a champion who will defend it. (3:640/531.42) * Origin: Baddog BBS (1:218/903) .