• proposed new nodelist [1]

    From Frank Vest@1:218/903 to mark lewis on Tue Jul 23 07:24:04 2002
    On (22 Jul 02) mark lewis wrote to Frank Vest...

    Hello mark,

    nah leave them out if there's no modem. I don't think
    any software will choke on a line with no flags...
    I have no idea on this. Some Guru that is better versed is
    modem capability flags are needed IF there is a modem answering the line... if it is telnet or some other network protocol, then other
    flags may be needed but not modem flags... unless we develop some
    "dual meaning" flags... one thing if modem, another if a certain
    network protocol...

    Ok. As long as it doesn't break things.

    The important thing is to have the order. The current
    Nodelist has the major flaw or being disorganized at the
    end. It's ok at the first... as you read the current list,
    you know that field one is "A", two is "B", three is "C",
    four is "D" and co on. Then you get to the flags and it
    falls apart. If a Node is CM, but not MO, the order is
    all messed up and hard to translate.... at least to me.
    the thing to remember here is that the flags after the speed field are
    all grouped together as a(nother) comma seperated field... and it is possible (of course) to have an additional comma seperated field in
    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.



    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


    But it won't. That is what is confusing to me. It would be like
    listing the phone field as:


    Or worse,


    I often laugh at the thought of putting a user flag in
    like "U,I'm_the"biggest_stud_in_Fidonet_Prove_me_wrong"
    yes, but that one shouldn't be allowed by the *C processing that
    segment because it is frivilous and doesn't serve any technical function(s)...

    Ok, True. :)

    The conversion program could use a configuration file to
    set what sections of the new list are used in what order
    for the old list.
    uggg... that leave too much open to go wrong... someone could adjust
    that line in the config file and then that row or entire segment might
    be dropped by the processing software due to something being

    But it does allow for growth since the fields can be changed, added
    to, and such for changes in format needed in the future.

    If the flag IBN, ITN or some other "I" flag exists, the
    node would be at least Internet capable.
    that might be possible but it could also be restricting in the
    future... better to have a complete new field similar to my proposal
    of an additional leading field containing the connection type for the row...





    --- PPoint 3.01
    # Origin: Holy Cow! I'm A Point!! (1:124/6308.1)
    * Origin: Baddog BBS (1:218/903)