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