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,<phone number or
JB> 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)
