Hi mark.

 ml> nope... the MNP flag means one thing... V42 means another... in
 ml> fact, as i recall, V42 was a speed and V42B is/was error
 ml> correction

I think V42 is eror recovery and V42B is compression as well as error
recovery.  V42 also implies MNP level 4 (because V42 is compatible with MNP
levels 1 to 4)

 JB>> some people may find them useful, ad flagging at bot the node and
 JB>> connection level should be allowed. maybe using a space for a
 JB>> flag separator instead of an underbar would solve that problem.

 ml> the thing to remember is that the nodelist is machine parsable...
 ml> it is not and never was intended to me for raw human
 ml> consumption... unless, like some programmers, you can read HEX in
 ml> the raw 

 :) I know a little machine code, but usually I use an assembler.

[snip]

 ml> right... this is why i personally want to be able to list my
 ml> system with its system name and domain name... in fact, i kinda
 ml> can see a method of further "compaction" of IP and POTS nodes by
 ml> reassigning some of the fixed fields when they appear in an IP
 ml> row... however, this would complicate my simple replacement of
 ml> existing data for subsequent lines proposal...


 JB>> depends what you mean by "wrong"... a certain zone 1
sysop who I
 JB>> meantioned earlier has some ususual ideas about what comprises a
 JB>> valid nodelist entry.


 ml> if that's sysop is who i think it is, he tends to push the
 ml> envelope on many things... reasoning is something like "if its not
 ml> explicitly disallowed, it must be allowed"..

 Hub,200,NY_Capital_Hub,Greater_Capital_District,Gregory_Deyss,1-000-000-0000,
 33600,CM,XA,V32b,V42b,V34,IFT,ITX

If you're to believe Gregorys flags, you can contact this node via IP or
modem but he doesn't publish a domain name, IP address, or phone number :)

Or am I reading it wrong? :)

 JB>> no. that's not what I mean at all. one connectio-type flag per
 JB>> connection. if they're posts only they start with a pots
 JB>> connection-type flag and omit the IP flag, if they're IP only
 JB>> then they omit the POTS connection.

 ml> my (2nd) proposal allows for just this... the 1st one does too but
 ml> it's harder to add additional capabilities to..

yeah, I disagree abot ease of programming though.


i intended the follling paragraphs to represent single lines in the
new nodelist, I just wrapped them to make them easier to read

 JB>> ,1701,Some_BBS_Name,Some_Town,Some_Sysop,system_flags,
 JB>> IP,IP.or.url.com,CM_MO_LO_IBN_ITN,
 JN>> POTS,,33600_V34_V42b_CM_XA

 JB>> ,1701,Some_BBS_Name,Some_Town,Some_Sysop,system_flags,
 JB>> POTS,,33600_V34_V42b_CM_XA

 JB>> ,1701,Some_BBS_Name,Some_Town,Some_Sysop,system_flags,
 JB>> IP,IP.or.url.com,CM_MO_LO_IBN_ITN

 ml> why not just put the indicator at the beginning of the row and
 ml> "meld" the info that is the same from the previous lines?

because I got tired of typing "(all on one line)" and assume that everyone
would assume it... (ani thusly made an ass of me atleast), I deal with what
I think you're asking in a few paragraphs, read on.

I also  forgot to say that for an uncontactable node it's be somethin like

  ,1701,Some_BBS_Name,Some_Town,Some_Sysop,system_flags

(no dummy connection with a blank or  "-Unpublished-" etc...)


however you do have a point, (of the sharp type)

My (badly specified) one-line format format could be changed to a multi
line format like your #2 by spltting off the second and subsequent connections
and adding blank fields to the start of them (and reordering some of the
fields)

the reasons why I don't like that is because it's full of exceptions,
exceptions cause code complexity, and code complexity often causes bugs.

 ml> my second proposal allows for future connection types... all it
 ml> takes is defining the indicator for the new type and then adding a
 ml> row with the specific (and altered from the previous row(s)) data
 ml> needed for the connection type..

Yeah it's pretty much functionally equivalent to my proposal.

 ml> uh, you still have to read the list a line at the time...

you can _read_ it a character at a time if you want....

some things need to be done a node at a time (eg converting to SLF),
but you could still handle the data a connection at time...

IMO reading the nodleist a line aat a time is a bad idea, (especially my
proposal)

 ml> the only space problem is with current nodelist processing utils...
 ml> the spec and future utils would (have to!) allow or specifically
 ml> state what the limits are... i see no problems (currently) with limiting
 ml> line lengths to 255 characters in the new format as long as
 ml> conversion utils handled the >158 (i think it was) limit of any
 ml> utils currently in use... makenl being the main culprit, TTBOMK..

255?, that short? why?

GWbasic and Turbo pascal are dead languages.  most other langauises don't
have such restrictive string lenght limits.

IMO 255 might be a good field length limit...

for conversion the converter may need to be designed to trim non-essential
fields (like location, system name etc)to keep the lines short enough.

 ml> still have some problems with this format, i'm positive...
 ml> however, i cannot think of anything other than linelength parsing
 ml> at the moment..

yeah 255 is pretty cramped, way too short for my proposal.

 JB>> the fact that you can't fit all the information from this into a
 JB>> regular nodelist isn't a problem. users of the conversion
 JB>> software would set up some rules about which connection types
 JB>> they prefer and the software would examine the fileds and spit
 JB>> out a SLF nodeline with the most suitable connection type listed
 JB>> (or possibly PVT etc if nothing was suitable)

 ml> i disagree with the initial portion... _developers_ would set up
 ml> the rulesets... the users may select the rulesets their systems
 ml> can handle..

yeah, that's true,  once a rulset is made for mailer brand X version N it
should be distributed with the conversion tool, forcing users to deveop
their own software is a bad thing.

Probably fewer than 10 rulesets would suffice for 99% of fidonet

 JB>> grouping it makes it easier to scan in some languages (you could
 JB>> use a string searching function)

 ml> agreed but then coding for this stuff wouldn't be much "fun"
 ml> >

using the software's supposed to be fun, writing it is supposed to be easy,
as is modifying it :)

 -=> Bye <=-
---