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)