Subj : proposed new nodelist To : Jasen Betts From : mark lewis Date : Tue Jul 23 2002 01:25 am JB>>> yeah... gruping flags together like that makes sense FV>> Thank you. JB> I have got to proofread better than I have been... JB> everyone's being so nice, ignoring it. :) <> JB>>> or you copuld just leave it blank... the tranalstion JB>>> software could insert that word FV>> Good point. The commas would still need to be there, FV>> though. JB> yup, can't have a blank filed without commas. thus the format of my (second) proposal... FV>>> 9. Modem speed. 300 if IP node? JB>>> for converting it may be enought to just determine JB>>> the modem speed from the modem flags modem flags... FV>> Possible, I guess. Although I had a 2400 baud modem FV>> that could do error correction. JB> Hmm, there's no V22B flag for 2400 bps modems. JB> error correction would be MNP or V42 flags right! that's why 2400,MNP or 2400,V42 was/is a valid flag... actually, i think V42B instead of V42... this is one of those "confusing" flags set by the ITUT (if i got those letters correct)... one of the V42 entries is speed/compression capability and the other (V42B) is error correction... JB> (did they produce any MNP ot V42 modems incapable JB> of 2400bps ? - maybe the MNP flag would be enough) nope... the MNP flag means one thing... V42 means another... in fact, as i recall, V42 was a speed and V42B is/was error corrections [trim] FV>> The important thing is to have the order. The FV>> current Nodelist has the major flaw or being FV>> disorganized at the end. It's ok at the first... FV>> as you read the current list, you know that field FV>> one is "A", two is "B", three is "C", four is "D" FV>> and co on. Then you get to the flags and it falls FV>> apart. If a Node is CM, but not MO, the order is FV>> all messed up and hard to translate.... at least FV>> to me. JB> yeah, each flag has to be read and then translated JB> separeately but having them continue to the end of JB> the line cases problems making it hard to add further JB> ordered fields. true, if one is adding fields to the end of the row... [trim] FV>> User flags seem useless to me in most respects. JB> some people may find them useful, ad flagging at JB> bot the node and connection level should be allowed. JB> maybe using a space for a flag separator instead of JB> an underbar would solve that problem. the thing to remember is that the nodelist is machine parsable... it is not and never was intended to me for raw human consumption... unless, like some programmers, you can read HEX in the raw <> [trim] FV>> The "Nodelist updates" would only be for the new FV>> format. The old style list would be made from the FV>> new list in the proper order with the proper FV>> information in the proper places. It couldn't be FV>> any other way... at least as I see it. JB> yeah, there's no way to extraact a system named from a JB> sustem that uses that field for something else etc... right... this is why i personally want to be able to list my system with its system name and domain name... in fact, i kinda can see a method of further "compaction" of IP and POTS nodes by reassigning some of the fixed fields when they appear in an IP row... however, this would complicate my simple replacement of existing data for subsequent lines proposal... [trim] FV>> That would work. Like I said, the format of the new FV>> list is not a problem and is expandable. The old list FV>> is generated from the new list and has no way to be FV>> wrong... JB> depends what you mean by "wrong"... a certain zone 1 JB> sysop who I meantioned earlier has some ususual ideas JB> about what comprises a valid nodelist entry. if that's sysop is who i think it is, he tends to push the envelope on many things... reasoning is something like "if its not explicitly disallowed, it must be allowed"... FV>> if the conversion program is done right. The new list FV>> could have a flag at position 11 that indicated the FV>> type of connection.. IE: ION for Internet only - no FV>> POTS. IPN for Internet and POTS. Then the other flags FV>> could tell what "protocol" is available at that Node. FV>> IE: IBN for binkp and so on. JB> no. that's not what I mean at all. one connectio-type JB> flag per connection. if they're posts only they start JB> with a pots connection-type flag and omit the IP flag, JB> if they're IP only then they omit the POTS connection. my (2nd) proposal allows for just this... the 1st one does too but it's harder to add additional capabilities to... JB> ,1701,Some_BBS_Name,Some_Town,Some_Sysop,system_flags, JB> IP,IP.or.url.com,CM_MO_LO_IBN_ITN, JB> 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, why not just put the indicator at the beginning of the row and "meld" the info that is the same from the previous lines?? FV>> The order of the fields isn't all that important in FV>> the new list. I'd suggest that the fields that are FV>> for Internet connection be before the fields for the FV>> POTS system in the new list simply because that is FV>> why we are doing a new list. JB> we're doing the new list because the existing list it JB> not easily extensible to a new type of connection while JB> trmaining compatible with existing software, I'm not in JB> favour of replacing it with something that still can't JB> take a new connection type. my second proposal allows for future connection types... all it takes is defining the indicator for the new type and then adding a row with the specific (and altered from the previous row(s)) data needed for the connection type... FV>> The important thing is that there be order in the new FV>> list. JB> no, doing that encourages people to read the list a line JB> at a time. that leads to problems if they don't allow JB> enough space for their line. uh, you still have to read the list a line at the time... the only space problem is with current nodelist processing utils... the spec and future utils would (have to!) allow or specifically state what the limits are... i see no problems (currently) with limiting line lengths to 255 characters in the new format as long as conversion utils handled the >158 (i think it was) limit of any utils currently in use... makenl being the main culprit, TTBOMK... FV>> IE: field 1 is for this and field 2 is for that JB> my way theres' 6 fixed fileds, then the rest come in JB> groups of 3 - field n is the address type (currently JB> POTS, ISDN, or IP) filed n+1 is the address (as JB> aproprtiate for the address type) field n+2 is flags JB> pertaining to that connection filed n+3 (if present) JB> indicates another connection is listed so you do n=n+3 still have some problems with this format, i'm positive... however, i cannot think of anything other than linelength parsing at the moment... JB> POTS and ISDN could be combined but it's hard to pick which JB> ISDN nodes don't handle POTS modems, for those systems, a simple ISDN indicator (falls into my second proposal) would suffice... if there is POTS and ISDN rows, then both are accepted... otherwise, one or the other... JB> the fact that you can't fit all the information from this JB> into a regular nodelist isn't a problem. users of the JB> conversion software would set up some rules about which JB> connection types they prefer and the software would JB> examine the fileds and spit out a SLF nodeline with the JB> most suitable connection type listed (or possibly PVT etc JB> if nothing was suitable) i disagree with the initial portion... _developers_ would set up the rulesets... the users may select the rulesets their systems can handle... FV>> and so on. That way we have each field defined. Also, do FV>> not make a field that "might be used in by this node, but FV>> not by another node"... IE: the flags field should have FV>> been grouped together in the old style list. If they had FV>> been, we would not be having so much trouble with the darn FV>> thing now IMHO. :-) JB> grouping it makes it easier to scan in some languages (you JB> could use a string searching function) agreed but then coding for this stuff wouldn't be much "fun" <> [trim] )\/(ark * Origin: (1:3634/12) --- SBBSecho/Win32 v2.00 * Origin: Baddog BBS (1:218/903) .