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. :)
<<GG>>
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 <<wink wink>>
[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,<phone number or unlisted>,33600_V34_V42b_CM_XA
JB> ,1701,Some_BBS_Name,Some_Town,Some_Sysop,system_flags,
JB> POTS,<phone number or unlisted>,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" <<wink>>
[trim]
)\/(ark
* Origin: (1:3634/12)
--- SBBSecho/Win32 v2.00
* Origin: Baddog BBS (1:218/903)
