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

 JB> I think V42 is eror recovery and V42B is compression
 JB> as well as error recovery.

nope... its only one or the other... that was one of the first confusing
flags i've run into...

[trim]

 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
 ml>> its not explicitly disallowed, it must be allowed"..

 JB>  Hub,200,NY_Capital_Hub,Greate
 JB> r_Capital_District,Gregory_Deyss,1-000-000-0000,
 JB>  33600,CM,XA,V32b,V42b,V34,IFT,ITX

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

 JB> Or am I reading it wrong? :)

you are not reading it wrong... and its not who i was thinking it may have been...

 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..

 JB> yeah, I disagree abot ease of programming though.

i dunno... i'm visualizing the flow in pascal (actually)... i'm just seeing
the first row filled and then the reading of the next line and parsing it
for each field just not being that hard... and then to overlay the changed
fields on the old, no biggie... kinda like using a buffer to store the data
in and then using different structures that are overlaid right on top of
that buffer... gosh, what is/was the term used for that?

[time passes]

the definition in PASCAL would be like this (taken from one of my PKT
analysis programs)

var
    bheader : bulkheader;
    header1 : pkthead1 absolute bheader;
    header2 : pkthead2 absolute bheader;
    header3 : pkthead3 absolute bheader;

that's just the variables that one works with... the actual structures were
defined in the TYPE section... bulkheader was simply defined as an
array[1..58] of byte...

 JB> i intended the follling paragraphs to represent single
 JB> lines in the new nodelist, I just wrapped them to make
 JB> 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

understand but also hear others "screaming" about the
"bulkiness" and duplication of the data... that has always been a
bitch... "the nodelist is too large. why can't we cut it down in
physical size?"

 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?

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

'k...

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

 JB>   ,1701,Some_BBS_Name,Some_Town,Some_Sysop,system_flags

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


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

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

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

i see that you came to the same conclusions i did and by kinda the same
methods that i did...

 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..

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

kinda...

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

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

true but it'll still build out to be a line once you get to the line terminator...

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

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

that's pretty much how most nodelist processors do it...

  readln(infile,linebuff);
  [determine if line is to be copied to output]
  [ if yes, then]
      listcrc := updatecrc(linebuff);
  [ else ]
  [loop to top and get next line]

 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..

 JB> 255?, that short? why?

ummm, turbo pascal is still used by many newbie (and long time)
developers... not to mention that there are even bbs message base formats
built on that particular limit... the HMB MSGTXT.BBS file is one such...
nothing but rows of strings...

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

while TP might be "dead" is it still in widespread use... in
fact, i'm personally aware of several bbs packages and related products
that are produced with TP... some even as old as TP 5.0...

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

 JB> for conversion the converter may need to be designed to trim
 JB> non-essential fields (like location, system name etc)to keep
 JB> 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..

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

and too short for my single line proposal, too... that's one of the main
reasons why i looked to the multiline 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..

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

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

agreed... and my thoughts are that they'd likely be coded in the program
and this reside in the .EXE (to use dos think for a moment)...

 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>> >

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

hehehe, i can see that you didn't graduate from the same school as i did
>  i actually enjoy coding... well, did a lot more some
years ago until major burnout caused me to have to step back for many
months...

)\/(ark