Subj : proposed new nodelist
To : Frank Vest
From : Jasen Betts
Date : Tue Jul 16 2002 03:34 pm
Hi Frank.
15-Jul-02 04:01:56, Frank Vest wrote to Jasen Betts
FV> Ok. Hang in there with me. I'll try to make this short (yeah,
FV> right :-)
LOL... You've got me laughing.
I've been taking this whole business too seriously.
FV> New Nodelist format (all on one line):
FV> 1. The Node number. Well, duh, that's the prime thing, isn't it?
Gotta have that.
FV> 2. The system name. This is an "address book, after all. :)
Sometimes useful for advertising.
FV> 3: The location of the system. Well, to generate an "old style" list,
FV> this is needed and is nice to know anyway.
Yeah.
FV> 4. The name of the operator of the system. Good to have since we are
FV> dealing with human beings here. :-)
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.
yeah... gruping flags together like that makes sense
FV> 8. FV> The phone number if POTS capable. If not, -Unpublished-.
or you copuld just leave it blank... the tranalstion software could insert
that word
FV> 9. Modem speed. 300 if IP node?
for converting it may be enought to just determine the modem speed from the
modem flags modem flags...
10. Modem flags. If IP only, make something
FV> up for the "old style" list.
nah leave them out if there's no modem. I don't think any software will
choke on a line with no flags...
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.
yeah it's gotta be open ended, that way new development can be added.
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.
reading FTS0005 I see that user flags could then can contain any printable
characters except the comma and blank... (which could be a problem)
FTS5001 calls the Tzz (hours of availability) flag a userflag but lits
it in the main flags section... (I'm guessing that it has been promoted to
the status of an availability flag and the word userflag in 5001 is an
oversight.
5001 also lists a bunch of "system" userflags that don't apply to a single
connection but to the fido node itself, (things like NEC)
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.
yeah the ease of conversion would be an advantage.... but there are already
nodes that don't fit the current nodelist format well...
FV> Now, make one more program to generate a diff/node list for the
FV> new style and you're done.
FV> Maybe I'm off base here. I don't know. The format of the new list
FV> isn't that critical to me. User readable would be nice.
yeah.
FV> Ability to generate an old style list is required... at least until
FV> there are no more mailers requiring that style of list.
definatey.
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.
The main thinh I want is a way that the new way can be introduced without
compromising the functioning of existing nodes...
what I'm proposing is at the least a connection-type field
that holts a indicator of what type of connecton is escribed after it,
if the new-format mailer can't handle that type of connection it justs
skips forwards three (or some other fixed nimber commas) and reads the next
connection-type
all you'd need to add is a type field before each address-flags pair.
then you could even list multiple telephone lines in one nodelist entry.
eg,
||
\/
,6308,Some_BBS_Name,Some_Town,Some_Sysop,IP,IP.or.url.com,
CM_MO_LO_IBN_ITN,POTS,<phone number or unlisted>,33600_V34_V42b_CM_XA
/\
||
Here I've grouped all the flags for each connection into a single field
and put the modem speed in there too.
probablly the system flags shoulf go before the firrst connection.
It won't be quite as simple to translate into an old-stype nodelist
because the correct answer depends on what the target sysytem is capable
of...
but that needn't be a bad thing, because the sysop can have a mailer that
is better behaved without neeing to upgrade it...
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.
if the format is designed in the right way it can be made extendable
with causing the headaches current nodelist format problems cause...
FV> This will require new programs to
FV> make things work and conversion programs for backward
FV> compatibility.
yeah.
FV>
http://pages.sbcglobal.net/flv http://biseonline.com/r19
-=> Bye <=-
---
# Origin: Iron Law of Distribution: Them that has, gets. (3:640/531.42)
* Origin: Baddog BBS (1:218/903)
