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