Subj : proposed new nodelist To : Jasen Betts From : mark lewis Date : Wed Jul 24 2002 06:57 pm 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 * Origin: (1:3634/12) --- SBBSecho/Win32 v2.00 * Origin: Baddog BBS (1:218/903) .