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 <<GG>
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>> <<<GGG>>>> 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)
