Subj : proposed new nodelist
To   : Frank Vest
From : Jasen Betts
Date : Fri Jul 19 2002 10:46 am

Hi Frank.

17-Jul-02 20:04:26, Frank Vest wrote to Jasen Betts

JB>> yeah... gruping flags together like that makes sense

FV> Thank you.

I have got to proofread better than I have been... everyone's being so
nice, ignoring it. :)

JB>> or you copuld just leave it blank... the tranalstion software could
JB>> insert that word

FV> Good point. The commas would still need to be there, though.

yup, can't have a blank filed without commas.

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...

FV> Possible, I guess. Although I had a 2400 baud modem that could do
FV> error correction.

Hmm, there's no V22B flag for 2400 bps modems.
error correction would be MNP or V42  flags
(did they produce any MNP ot V42 modems incapable of 2400bps ? -
maybe the MNP flag would be enough)


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...

FV> 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.

FV> The important thing is to have the order. The current Nodelist has the
FV> major flaw or being disorganized at the end. It's ok at the first...
FV> as you read the current list, you know that field one is "A", two is
FV> "B", three is "C", four is "D" and co on. Then you get to the flags
FV> and it falls apart. If a Node is CM, but not MO, the order is all
FV> messed up and hard to translate.... at least to me.

yeah, each flag has to be read and then translated separeately
but having them continue to the end of the line cases problems making it
hard to add further ordered fields.

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)

FV> User flags seem useless to me in most respects.

some people may find them useful, ad flagging at bot the node and
connection level should be allowed. maybe using a space for a flag
separator instead of an underbar would solve that problem.

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...

FV> Hmmm... You've brought up a "plus" that I hadn't considered. Let's see
FV> if I can explain it. :-)

FV> Since the "old style" Nodelist will be generated from the new Nodelist
FV> format, the "old style" Nodelist would have to be correct. Think about
FV> this.

FV> The format of the new list is set in order. It's not important what
FV> section come first, second, third and so forth in the new list. It
FV> could be the system name, then the node number, then the flags then
FV> whatever... The fact that there is an order here is important.

FV> The delimiter is not important. A "|" could be used, or any character
FV> decided on. The fact that there is order and some separator counts.

huh?

FV> The conversion program could use a configuration file to set what
FV> sections of the new list are used in what order for the old list.

FV> The "Nodelist updates" would only be for the new format. The old style
FV> list would be made from the new list in the proper order with the
FV> proper information in the proper places. It couldn't be any other
FV> way... at least as I see it.

yeah, there's no way to extraact a system named from a sustemthat uses that
field for something else etc...

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...

FV> 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

FV> If the flag IBN, ITN or some other "I" flag exists, the node would be
FV> 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>>                    ||

JB>>  Here I've grouped all the flags for each connection into a single
JB>> field  and put the modem speed in there too.

FV> That would work. Like I said, the format of the new list is not a
FV> problem and is expandable. The old list is generated from the new list
FV> and has no way to be wrong...

depends what you mean by "wrong"... a certain zone 1 sysop who I meantioned
earlier has some ususual ideas about what comprises a valid nodelist entry.

FV> if the conversion program is done right.
FV> The new list could have a flag at position 11 that indicated the type
FV> of connection.. IE: ION for Internet only - no POTS. IPN for Internet
FV> and POTS. Then the other flags could tell what "protocol" is available
FV> at that Node. IE: IBN for binkp and so on.

no. that's not what I mean at all. one connectio-type flag per connection.
if they're posts only they start with a pots connection-type flag and omit
the IP flag, if they're IP only then they omit the POTS connection.

,1701,Some_BBS_Name,Some_Town,Some_Sysop,system_flags,
  IP,IP.or.url.com,CM_MO_LO_IBN_ITN,
  POTS,<phone number or unlisted>,33600_V34_V42b_CM_XA

,1701,Some_BBS_Name,Some_Town,Some_Sysop,system_flags,
  POTS,<phone number or unlisted>,33600_V34_V42b_CM_XA

,1701,Some_BBS_Name,Some_Town,Some_Sysop,system_flags,
  IP,IP.or.url.com,CM_MO_LO_IBN_ITN,

FV> The order of the fields isn't all that important in the new list. I'd
FV> suggest that the fields that are for Internet connection be before the
FV> fields for the POTS system in the new list simply because that is why
FV> we are doing a new list.

we're doing the new list because the existing list it not easily extensible
to a new type of connection while trmaining compatible with existing
software, I'm not in favour of replacing it with something that still can't
take a new connection
type.

FV> The important thing is that there be order in the new list.

no, doing that encourages people to read the list a line at a time.
that leads to problems if they don't allow enough space for their line.

FV> IE: field 1 is for this and field 2 is for that

my way theres' 6 fixed fileds, then the rest come in groups of 3 -
field n is the address type (currently POTS, ISDN, or IP)
filed n+1 is the address (as aproprtiate for the address type)
field n+2 is flags pertaining to that connection

filed n+3 (if present) indicates another connection is listed
so you do n=n+3

POTS and ISDN could be combined but it's hard to pick which ISDN nodes
don't handle POTS modems,

the fact that you can't fit all the information from this into a regular
nodelist isn't a problem. users of the conversion software would set up
some rules about which connection types they prefer and the software would
examine the fileds and spit out a SLF nodeline with the most suitable
connection type listed (or possibly PVT etc if nothing was suitable)

FV> and so on. That way we have each field defined. Also, do not make a
FV> field that "might be used in by this node, but not by another node"...
FV> IE: the flags field should have been grouped together in the old style
FV> list. If they had been, we would not be having so much trouble with
FV> the darn thing now IMHO. :-)

grouping it makes it easier to scan in some languages (you could use a
string searching function)

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...

FV> The old nodelist is generated from the new list. I'm not sure what you
FV> mean here. I'm probably not understanding properly.

If you've got a POTS system you don't domain names or need IP addresses in
the BBS-name or phone number fields,but if you have an IP system that could
be what you need.

JB>>  but that needn't be a bad thing, because the sysop can have a mailer
JB>> that  is better behaved without needing to upgrade it...

FV> I think that with the old nodelist being generated from the new list,
FV> there will be a lot of problems solved. :-)

yeah. but not all of them. uncontactable hubs and some other strange zone 1
inventions won't be deterred by a new nodelist and will come out of the
converter just as bogus .... unless we put some
tricks in the converter (like replacing connection info of the bogus hub
with that of their netmail feed, (or that of a local, or global, IP gateway)

JB>> if the format is designed in the right way it can be made extendable
JB>> without causing the headaches current nodelist format problems cause...

FV> Yup. As long as there are no fields that are used by one node, but not
FV> by others. Such fields should be grouped and not given an individual
FV> section. Otherwise, the structure of any list falls apart.

yeah, a structure is needed to constrain compartmentise the information.

FV> Sorry for the long reply.

bigger is better :)

FV> Regards,

FV>  Frank

FV> http://pages.sbcglobal.net/flv
FV> http://biseonline.com/r19

FV> -!- PPoint 3.01
FV>  - Origin: Holy Cow! I'm A Point!! (1:124/6308.1)

-=> Bye <=-

---
# Origin: "Qvid me anxivs svm?" (3:640/531.42)
* Origin: Baddog BBS (1:218/903)

You are viewing proxied material from cvs.synchro.net. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.