Subj : proposed new nodelist [1] To : mark lewis From : Frank Vest Date : Tue Jul 23 2002 07:24 am On (22 Jul 02) mark lewis wrote to Frank Vest... Hello mark, ml> JB>> nah leave them out if there's no modem. I don't think ml> JB>> any software will choke on a line with no flags... FV> I have no idea on this. Some Guru that is better versed is FV> needed. ml> modem capability flags are needed IF there is a modem answering the ml> line... if it is telnet or some other network protocol, then other ml> flags may be needed but not modem flags... unless we develop some ml> "dual meaning" flags... one thing if modem, another if a certain ml> network protocol... Ok. As long as it doesn't break things. FV> The important thing is to have the order. The current FV> Nodelist has the major flaw or being disorganized at the FV> end. It's ok at the first... as you read the current list, FV> you know that field one is "A", two is "B", three is "C", FV> four is "D" and co on. Then you get to the flags and it FV> falls apart. If a Node is CM, but not MO, the order is FV> all messed up and hard to translate.... at least to me. ml> the thing to remember here is that the flags after the speed field are ml> all grouped together as a(nother) comma seperated field... and it is ml> possible (of course) to have an additional comma seperated field in ml> there known as U(ser) flags... My point was that after a certian point in the Nodelist, the flags might or might not be there and each has it's own field. IE: CM,MO,LO,XA,V32,HST If the Node is CM and the other flags are not needed, the commas that delimit those fields are not there. So, if a software is trying to read the list in some numbered order to determine, say, the connectivity flags and the modem flags for a node, it should expect to find: CM,,,XA,V32,HST But it won't. That is what is confusing to me. It would be like listing the phone field as: 1,972,562,8064 Or worse, ,6308,collin,county,station,mckinney,tx,frank,vest, FV> I often laugh at the thought of putting a user flag in FV> like "U,I'm_the"biggest_stud_in_Fidonet_Prove_me_wrong" FV> :-)) ml> yes, but that one shouldn't be allowed by the *C processing that ml> segment because it is frivilous and doesn't serve any technical ml> function(s)... Ok, True. :) FV> The conversion program could use a configuration file to FV> set what sections of the new list are used in what order FV> for the old list. ml> uggg... that leave too much open to go wrong... someone could adjust ml> that line in the config file and then that row or entire segment might ml> be dropped by the processing software due to something being ml> invalid... But it does allow for growth since the fields can be changed, added to, and such for changes in format needed in the future. FV> If the flag IBN, ITN or some other "I" flag exists, the FV> node would be at least Internet capable. ml> that might be possible but it could also be restricting in the ml> future... better to have a complete new field similar to my proposal ml> of an additional leading field containing the connection type for the ml> row... Ok. Reards, Frank http://pages.sbcglobal.net/flv http://biseonline.com/r19 --- PPoint 3.01 # Origin: Holy Cow! I'm A Point!! (1:124/6308.1) * Origin: Baddog BBS (1:218/903) .