Subj : proposed new nodelist To : mark lewis From : Jasen Betts Date : Wed Jul 24 2002 02:45 pm 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 <=- --- # Origin: Only adults have difficulty with childproof caps. (3:640/531.42) * Origin: Baddog BBS (1:218/903) .