Subj : proposed new nodelist [2]
To : Frank Vest
From : Jasen Betts
Date : Sun Jul 21 2002 09:58 am
Hi Frank.
20-Jul-02 01:36:46, Frank Vest wrote to Jasen Betts
FV> The translation software would make the old style list and take only
FV> what is required for that list from the new style. No matter what the
FV> Node put in the new style, the old style would almost certianly be
FV> correct... I think.
Maybe syntatically correct... there'd still be uncontactable hosts, etc,
so it wouldn't be functionally correct.
FV> Of course, nothing is fool proof. :-))
FV> Ah ha! I think I see what you mean. The new style list would have two
FV> or three lines for each Node
nah, one line, I just split them that way for easier reading. (I should
have said) the POTS section has the same number of commas as the IP section
or any other type or connection, so if old(future) sofrware finds something
it doesn't understand it knows to just skip 3 commas and there'll be another
connection to look at (or a new line with a new node).
FV> . The first line would always be the
FV> "basic" Node information. The next line(s) would depend on the type of
FV> connection capabilities and be designated by either the POTS or IP
FV> flag, or both, as needed? If I got this thought my thick head right?
Pretty much, but also ISDN atleast where where it's incompatible with POTS
PACNet too if it's still running, even packet radio if someone's got X25
fido software and there's no rules against it...
FV> This would work just fine with me... Probably be easier to read and
FV> translate to boot.
I hadn't thought of that but, having a reminder (int the form of
connection-type keyword) every three fields would reduce the "forest of
commas" problem
FV> I was thinking that the *Cs would be the ones running the conversion
FV> program to generate the old style list for distribution along with the
FV> new list... IE:
they could but the node in their net may be sing different software and
therfore want different information in their nodelist.
those with IP nodes would want IP numbers, those with modems would want
phone numbers, those with a different brand of modem might want a different
phone number etc...
And for each of these nodes the NC has to keep a current nodelist and then
build a new one, compare the two and then produce a diff.
the NC would could end up with 10 copies of the nodelist produced with
different options turned on or off sitting on his hard disk taking up
space.
If the new nodelist could be produced with correnspnding line numbers
holding the same information as the old nodelist that could help, (then the
nodediff could jut be translated for each different node) I'm not sure how
practical that would be. (personally I don't like that idea because it would
put restrictions on the new nodelist)
possibly a nodediff translater could be made that would work without an
existing old nodelist (just using the week-old new nodelist and the new
nodediff) it'd be an interesting challenge... especially a multi-headed
version that could produce multiple old nodediffs simultaneously....
FV> New Style List = nodeip.*
FV> Old Style from conversion program = nodelist.* (just as always).
JB>> yeah. but not all of them. uncontactable hubs and some other strange
JB>> zone 1 inventions won't be deterred by a new nodelist and will come
JB>> out of the converter just as bogus ....
FV> Remember, Nothing is fool proof because fools are so ingenious. :-))
yeah, you've got a point there....
FV> Actually, you are right. There will still be some problems, but it
FV> might be easier to deal with those problems... I dunno.
It'll help I expect.
-=> Bye <=-
---
# Origin: To err is human - two curs canine. (3:640/531.42)
* Origin: Baddog BBS (1:218/903)
