Subj : proposed new nodelist To : Jasen Betts From : Frank Vest Date : Wed Jul 17 2002 10:04 pm On (16 Jul 02) Jasen Betts wrote to Frank Vest... Hello Jasen, FV> Ok. Hang in there with me. I'll try to make this short (yeah, FV> right :-) JB> LOL... You've got me laughing. JB> I've been taking this whole business too seriously. Birth is serious. Death is serious. Everything in between is only to pass the time. :-) I get too serious at times too. :) I'm leaving the number lines in to benefit others who read this. :) FV> New Nodelist format (all on one line): FV> 1. The Node number. Well, duh, that's the prime thing, isn't it? JB> Gotta have that. Yup. FV> 2. The system name. This is an "address book, after all. :) JB> Sometimes useful for advertising. True. I also like to know the name of the system I'm calling... especially if I'm calling a BBS. Something about telneting to "web-idiot.d2g.com" and finding a BBS named "Collin County Station" is a little strange. :-) FV> 3: The location of the system. Well, to generate an "old style" list, FV> this is needed and is nice to know anyway. JB> Yeah. FV> 4. The name of the operator of the system. Good to have since we are FV> dealing with human beings here. :-) JB> definitely essential FV> 5. The IP address or URL for DNS look up. 6. The "availability FV> flags". I think these are pretty common in translation between FV> Internet capable and POTS systems? 7. The Internet capability flags. JB> yeah... gruping flags together like that makes sense Thank you. FV> 8. FV> The phone number if POTS capable. If not, -Unpublished-. JB> or you copuld just leave it blank... the tranalstion software could JB> insert that word Good point. The commas would still need to be there, though. FV> 9. Modem speed. 300 if IP node? JB> for converting it may be enought to just determine the modem speed JB> from the modem flags modem flags... Possible, I guess. Although I had a 2400 baud modem that could do error correction. JB> 10. Modem flags. If IP only, make something FV> up for the "old style" list. JB> nah leave them out if there's no modem. I don't think any software JB> will choke on a line with no flags... I have no idea on this. Some Guru that is better versed is needed. FV> Ok. You can add all the bs you want after this. Why, I don't know. FV> Doesn't seem to make any sense or be needed, but who knows. JB> yeah it's gotta be open ended, that way new development can be added. The important thing is to have the order. The current Nodelist has the major flaw or being disorganized at the end. It's ok at the first... as you read the current list, you know that field one is "A", two is "B", three is "C", four is "D" and co on. Then you get to the flags and it falls apart. If a Node is CM, but not MO, the order is all messed up and hard to translate.... at least to me. FV> Now, make a program that will read this new list and spit out an FV> old style list. The new list is formatted in such a way that the FV> fields are set and clear. The program would read the new list and FV> know what needed to go where for the old list. JB> reading FTS0005 I see that user flags could then can contain any JB> printable characters except the comma and blank... (which could be a JB> problem) JB> FTS5001 calls the Tzz (hours of availability) flag a userflag but JB> lits it in the main flags section... (I'm guessing that it has been JB> promoted to the status of an availability flag and the word userflag JB> in 5001 is an oversight. JB> 5001 also lists a bunch of "system" userflags that don't apply to a JB> single connection but to the fido node itself, (things like NEC) User flags seem useless to me in most respects. I often laugh at the thought of putting a user flag in like "U,I'm_the"biggest_stud_in_Fidonet_Prove_me_wrong" :-)) FV> IE: for an old style list, use fields 1,2,3,4,8,6,10,7 in that order. FV> You could have it use field 5 for field 2 for the "proper" way to FV> list an ION's IP address in the old style if desired. The "flags" FV> would need to be separated by commas where the underscore is, but the FV> program can do that as well. JB> yeah the ease of conversion would be an advantage.... but there are JB> already nodes that don't fit the current nodelist format well... Hmmm... You've brought up a "plus" that I hadn't considered. Let's see if I can explain it. :-) Since the "old style" Nodelist will be generated from the new Nodelist format, the "old style" Nodelist would have to be correct. Think about this. The format of the new list is set in order. It's not important what section come first, second, third and so forth in the new list. It could be the system name, then the node number, then the flags then whatever... The fact that there is an order here is important. The delimiter is not important. A "|" could be used, or any character decided on. The fact that there is order and some separator counts. The conversion program could use a configuration file to set what sections of the new list are used in what order for the old list. The "Nodelist updates" would only be for the new format. The old style list would be made from the new list in the proper order with the proper information in the proper places. It couldn't be any other way... at least as I see it. FV> IMHO, No matter what we create; new Nodelist format, DNS look up FV> or ???, it will be obsolete in time and require a "new way" to do FV> it. JB> The main thinh I want is a way that the new way can be introduced JB> without compromising the functioning of existing nodes... Yes. JB> what I'm proposing is at the least a connection-type field JB> that holts a indicator of what type of connecton is escribed after it, JB> if the new-format mailer can't handle that type of connection it justs JB> skips forwards three (or some other fixed nimber commas) and reads the JB> next connection-type If the flag IBN, ITN or some other "I" flag exists, the node would be at least Internet capable. JB> all you'd need to add is a type field before each address-flags pair. JB> then you could even list multiple telephone lines in one nodelist JB> entry. eg, JB> || JB> \/ JB> ,6308,Some_BBS_Name,Some_Town,Some_Sysop,IP,IP.or.url.com, JB> CM_MO_LO_IBN_ITN,POTS, unlisted>,33600_V34_V42b_CM_XA /\ JB> || JB> Here I've grouped all the flags for each connection into a single JB> field and put the modem speed in there too. That would work. Like I said, the format of the new list is not a problem and is expandable. The old list is generated from the new list and has no way to be wrong... if the conversion program is done right. The new list could have a flag at position 11 that indicated the type of connection.. IE: ION for Internet only - no POTS. IPN for Internet and POTS. Then the other flags could tell what "protocol" is available at that Node. IE: IBN for binkp and so on. JB> probablly the system flags shoulf go before the firrst connection. The order of the fields isn't all that important in the new list. I'd suggest that the fields that are for Internet connection be before the fields for the POTS system in the new list simply because that is why we are doing a new list. :-) The important thing is that there be order in the new list. IE: field 1 is for this and field 2 is for that and so on. That way we have each field defined. Also, do not make a field that "might be used in by this node, but not by another node"... IE: the flags field should have been grouped together in the old style list. If they had been, we would not be having so much trouble with the darn thing now IMHO. :-) JB> It won't be quite as simple to translate into an old-stype nodelist JB> because the correct answer depends on what the target sysytem is JB> capable of... The old nodelist is generated from the new list. I'm not sure what you mean here. I'm probably not understanding properly. JB> but that needn't be a bad thing, because the sysop can have a mailer JB> that is better behaved without neeing to upgrade it... I think that with the old nodelist being generated from the new list, there will be a lot of problems solved. :-) FV> No matter what format we use; comma delimited, data base, FV> magic wand or ???, the format will need to be changed in time to FV> allow different protocols, communication methods and other FV> advancements that come along. JB> if the format is designed in the right way it can be made extendable JB> with causing the headaches current nodelist format problems cause... Yup. As long as there are no fields that are used by one node, but not by others. Such fields should be grouped and not given an individual section. Otherwise, the structure of any list falls apart. Sorry for the long reply. Regards, Frank http://pages.sbcglobal.net/flv http://biseonline.com/r19 --- PPoint 3.01 # Origin: Holy Cow! I'm A Point!! (1:124/6308.1) * Origin: Baddog BBS (1:218/903) .