• proposed new nodelist

    From Jasen Betts@3:640/531.42 to mark lewis on Fri Jul 26 09:49:41 2002
    why noty use the extensions to reduce size of the fixed component
    to the essentials.

    i just see no need to go to that level... plain ASCII text is fine
    and we don't really need to go adding <TAG></TAG>'s to everything,
    do we

    I was just describing my proposal.... with 6 fixed fileds and then 3*n
    optional fileds... each 3 fileds describing a connection method,
    I wasn't suggesting XML style tags... I 've given up on them.

    then you loose the placeholders... they are needed if they are
    the first row for that entry, too..

    what I meant was by putting POTS into the extension there's no
    need for empty fields, on non-pots systems.

    won't be any empty fields, i don't believe...

    how do you represent a private node?

    if is there's a flag on the first row that you don't want on the
    second row, what do you do...

    redefine that flag sequence on the subsequent row(s)

    huh?

    put it last on the fisrs row and use fewer commas on the second
    row? (could work but could trap many programmers)

    no, the flags section is a comma seperated list just like the
    row... kinda like an OOP object as a data item in another OOP
    object..

    huh? do you mean the flags section is treated like a single field?
    so if there are any flags on a line all the flags from the line above are ingnored for the current line?

    Bye <=-

    ---
    * Origin: Every solution breeds new problems. (3:640/531.42)
  • From Jasen Betts@3:640/531.42 to mark lewis on Fri Jul 26 09:58:29 2002
    Hi mark.

    24-Jul-02 16:57:34, mark lewis wrote to Jasen Betts


    nope... the MNP flag means one thing... V42 means another... in
    fact, as i recall, V42 was a speed and V42B is/was error
    correction

    I think V42 is eror recovery and V42B is compression as well as
    error recovery.

    nope... its only one or the other... that was one of the first
    confusing flags i've run into..

    AH, I was describing CCITT protocols, you were describibing flags with
    similar names. ir makes sense that old software wouldn't know that V42b
    implies V42. (according to CCITT) so the fido docs say you should indicate
    both if if you do V42b.

    i dunno... i'm visualizing the flow in pascal (actually)... i'm
    just seeing the first row filled and then the reading of the next
    line and parsing it for each field just not being that hard... and
    then to overlay the changed fields on the old, no biggie... kinda
    like using a buffer to store the data in and then using different structures that are overlaid right on top of that buffer... gosh,
    what is/was the term used for that

    [time passes]

    pkthead1 absolute bheader;

    You can't just "absolute" them over each other because then reading one
    would erase the next...

    understand but also hear others "screaming" about the "bulkiness"
    and duplication of the data... that has always been a bitch...
    "the nodelist is too large. why can't we cut it down in physical
    size?

    size doesn't really worry me... sure whn it was 3 megs it took about 20% of
    my hard space to edit it (for a friend with an amiga who didn't have enough
    ram - neither did I but wordstar doesn't need big ram to edit a big file)

    true but it'll still build out to be a line once you get to the
    line terminator..

    depends how you code the reading...

    255?, that short? why?

    ummm, turbo pascal is still used by many newbie (and long time) developers... not to mention that there are even bbs message base
    formats built on that particular limit... the HMB MSGTXT.BBS file
    is one such... nothing but rows of strings..

    so pascal programmer will have to treat a long-line file as lines
    containing fileds rather than just a bunch of strings,

    as soon as they decide to they can ignore a line they can do READLN; and they'll be at the next line.

    they'll have to use a "readfield" procedure for getting the data from the
    file into strings but that shouldn't be a big hassle, they only need to
    write it once, and can use it for all fields. if done using the ttextrec object (actually not "ttextrec", but that's the naem in the online help) it needn't mean yhe inefficinet practice of repeatedly reading a single
    character searching for a comma.)

    yeah 255 is pretty cramped, way too short for my proposal.

    Probably fewer than 10 rulesets would suffice for 99% of fidonet

    agreed... and my thoughts are that they'd likely be coded in the
    program and this reside in the .EXE (to use dos think for a
    moment)..

    could be, but that makes upgrades hard on the bandwidth unless external rulesets can be used too.

    Bye <=-

    ---
    * Origin: He who Laughs, Lasts. (3:640/531.42)
  • From Jasen Betts@3:640/531.42 to Goran Eriksson on Fri Jul 26 12:58:08 2002
    Hi Goran.

    24-Jul-02 19:00:48, Goran Eriksson wrote to Haakan Karlsson

    Secondly, how would you convert a zone or region independent
    entry that doesn't announce any POTS capability?

    I don't recognize the problem, maybe I am overlooking something
    in how the nodelist works.

    Converting such a node to a Pvt listing might cause problems.

    FTS-5000 says:

    Pvt --Defines a private node with unlisted number. Private nodes
    are only allowed as members of local networks.

    Even my oldest copy of the FidoNet nodelist specification (FSC-2
    dated 1988-01-02) has an identical requirement. (I would
    appreciate pointers to any other versions of FSC-2, other versions
    of FTS-2 than 1988-11-06 and/or other versions of FTS-5 than
    1989-02-05, 1996-06-01 and 2001-01-03.

    I've not been able to find any explicit, trustworthy and
    contemporary motivation for this requirement, but I'm speculating
    as follows

    The only ones required by administrative FidoNet policy to offer
    inbound netmail routing are the network hosts. (I know that many
    ZC's, RC's and hubs do the same, but that's another thing.)

    Therefore putting a Pvt node outside a local network (e.g. as
    region or zone independents) would mean that there is noone who is required (by policy) to forward netmail to that node

    the ZC is responsible for the contents of the nodelist, if there are unreachable nodes then IMO the ZC (or RC) is responsible for their mail.

    In any case, MakeNl vigorously enforces this restriction

    Yeah, so people put fictional phonen numbers in...
    it's still a private node, it just doesn't look like one to makenl
    (and many other nodelist handling programs).

    and
    therefore I wouldn't be surprised if some other nodelist
    processing tool also rejects such nodes. Furthermore, it would be
    nice to have the 'old style' nodelist so compatible with MakeNl
    that MakeNl can be used to recreate a missing nodediff from two
    'old style' nodelists created by the sort of conversion programs
    that has been discussed here

    sure, a makenl compatible version would be one of the options.

    Bye <=-
    ---
    * Origin: November: The eleventh twelfth of a weariness. (3:640/531.42)
  • From Jasen Betts@1:218/903 to Goran Eriksson on Tue Jul 16 12:43:44 2002
    Hi Goran.

    14-Jul-02 11:07:00, Goran Eriksson wrote to Haakan Karlsson

    As long as all the needed information is included in the new
    format, the compatibility issue can be easily solved by a
    convertion program that outputs an old style nodelist that can
    serve as input to the old software.

    There are at least a few cases where such a conversion isn't quite straightforward

    Firstly, how would you a convert a hub, host, region or zone entry
    that doesn't announce any POTS capability

    FTS-0005, 5001 etc say nothing whatsoever about how to crash-mail a PVT node (what document covers crashmail addressing? )

    Secondly, how would you convert a zone or region independent entry
    that doesn't announce any POTS capability? (I know that the
    current practice is to use the Hold keyword for indefinite periods
    of time. That means a redefinition of the meaning of the Hold
    keyword I'm not very fond of.

    Yeah, anything that stops mail from flowing without atleast producing an
    error message is a bad thing.

    I'd suggest automatically routing it theough their ZC RC or NC by putting
    that phone number on the ION. :-)


    Hmm a similar problem already exists:
    what if a point wants to crashmail someone flying the LO (listed only)
    flag.


    Hmm, does anyone know what's an "RVIA" flag for and where is it documented?

    Bye <=-

    ---
    # Origin: Only God can make random selections. (3:640/531.42)
    * Origin: Baddog BBS (1:218/903)
  • From Jasen Betts@1:218/903 to Goran Eriksson on Tue Jul 16 13:04:46 2002
    Hi Goran.

    14-Jul-02 11:19:32, Goran Eriksson wrote to mark lewis


    personally, i don't see any problem/difference between ISDN and
    POTS other than one being digital and the other being analogue...
    i've never had any problem picking up my POTS telephone and
    calling someone with an ISDN phone and talking to them... yes, i
    know there are several variations of ISDN that are incompatible
    with each other but that is taken care of with the current ISDN
    flags, right?

    There is at least one form of incompatibility between a POTS only
    system and an ISDN only system that isn't quite straightforward
    from current nodelist practice

    That's when the ISDN system uses equipment that doesn't support
    any of the traditional telephony modem communication standards
    (but only digital ISDN standards)

    This is probably one such example from nodelist 2002:186:

    ,540,Minas_Morgul_BBS,Goettingen,Marius_Faust,49-551-7988024,300,CM ,XA,LO,X75

    Yes, it's possible to deduce that this system probably isn't
    reachable by a conventional modem for dial-up POTS lines only.

    a nodelist modifier could put that node on "hold" so that crashmail goes to
    its hub or coordinator


    The announced maximum data speed is 300 bps and there is no telephony modem communications standard (such as V.32bis, V.34 or V.90)
    announced

    yeah the lack of an analog protocol flag is a clue, even 300bps nodes
    should fly the a V21 flag.

    But I would be surprised if there is no mailer out there which at
    least may take some manual reconfiguration not to attempt calling
    that particular system when presented with a piece of non-routable
    mail destined there. Not to speak of what it would take to
    redirect that mail to the host or hub of such a destination

    The hold flag should do the trick as I read the specification.
    you can't put that flag in the distribution nodelist but putting it in the local copy should work.

    Bye <=-

    ---
    # Origin: Hummingbirds never remember the words to songs. (3:640/531.42)
    * Origin: Baddog BBS (1:218/903)
  • From Jasen Betts@1:218/903 to Frank Vest on Tue Jul 16 15:34:17 2002
    Hi Frank.

    15-Jul-02 04:01:56, Frank Vest wrote to Jasen Betts

    Ok. Hang in there with me. I'll try to make this short (yeah,
    right :-)

    LOL... You've got me laughing.
    I've been taking this whole business too seriously.

    New Nodelist format (all on one line):



    1. The Node number. Well, duh, that's the prime thing, isn't it?

    Gotta have that.

    2. The system name. This is an "address book, after all. :)

    Sometimes useful for advertising.

    3: The location of the system. Well, to generate an "old style" list,
    this is needed and is nice to know anyway.

    Yeah.

    4. The name of the operator of the system. Good to have since we are dealing with human beings here. :-)

    definitely essential

    5. The IP address or URL for DNS look up. 6. The "availability
    flags". I think these are pretty common in translation between
    Internet capable and POTS systems? 7. The Internet capability flags.

    yeah... gruping flags together like that makes sense

    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


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

    Ok. You can add all the bs you want after this. Why, I don't know.
    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.

    Now, make a program that will read this new list and spit out an
    old style list. The new list is formatted in such a way that the
    fields are set and clear. The program would read the new list and
    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)


    IE: for an old style list, use fields 1,2,3,4,8,6,10,7 in that order.
    You could have it use field 5 for field 2 for the "proper" way to
    list an ION's IP address in the old style if desired. The "flags"
    would need to be separated by commas where the underscore is, but the 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...

    Now, make one more program to generate a diff/node list for the
    new style and you're done.

    Maybe I'm off base here. I don't know. The format of the new list
    isn't that critical to me. User readable would be nice.

    yeah.

    Ability to generate an old style list is required... at least until
    there are no more mailers requiring that style of list.

    definatey.

    IMHO, No matter what we create; new Nodelist format, DNS look up
    or ???, it will be obsolete in time and require a "new way" to do
    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...

    No matter what format we use; comma delimited, data base,
    magic wand or ???, the format will need to be changed in time to
    allow different protocols, communication methods and other
    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...

    This will require new programs to
    make things work and conversion programs for backward
    compatibility.

    yeah.

    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)
  • From Jasen Betts@1:218/903 to mark lewis on Thu Jul 18 01:08:35 2002
    Hi mark.

    15-Jul-02 18:33:20, mark lewis wrote to Jasen Betts


    A comma separated list is not very flexible, but instead
    inherently quite rigid. A flexible format have to be built on
    field identifiers, that is the only way to guarantee future
    extentions without breaking existent next generation software.

    CSV databases have been used since the beginning of database
    information storage... yes, their format may be "rigid" but that
    is the same for all database formats...

    no it's not. relational databases don't have such limitations.

    they do, however, have specific fields in the tables and that data
    is stored in a specific place in the stream data... to me,
    relational databases are just that... databases of data that is
    linked together via some piece of info common in them... what folk
    see today as a table, i grew up with knowing is as a database...
    making the switch from a database to many linked via a piece of
    data between them was very easy for me... another term would be
    database of databases <<GG>

    once you go ro 5NF every filed is optional or may be repeated any numbrer
    of times (except the key field)...

    i don't believe that we should add any more info to the current
    database style other than what is absolutely necessary...

    information part of the style ?

    not sure of the reference... i was thinking of keeping the POTS
    data the same and building from there..

    why keep pots?

    what is necessary is something that'll work next year and keep
    working without a major overhaul (one that obsoletes software
    etc) a list of anonymous commas doesn't do that.

    my proposal do that with the requirement that someone still
    generate a SLF nodelist for those nodes that require the SLF
    nodelist..

    why have to add field identifiers and then have to create
    "smart" programs that have to be able to pick out the data they
    need no matter what order it is in?

    why not, it's not exaclty hard, if we're smart we'll be able to
    co-opt some freeware SGML or XML (etc) parsing library to the
    task (LGPL allows use if the library in commercial code)

    understood but why? what is wrong with using a fixed format that
    is extensible?

    that's what I was proposing :)

    heck, we could code some sort of comma-encoding to
    show number of empty comma fields is that is a problem..

    I'd prefer to make them optional.

    sure, we could code up some relational database FDNS and
    import/update the POTS data and have additional tables named for
    the functions served... POTS table, FTP table, IBN table, etc...
    that database would be easily extensible except for the fact that
    not all systems would have access and not all future system may
    have access to the internet as we know it today... it is, however,
    not much different from my proposal that we add another field to
    the front of the SLF nodelist to designate that line's use... it
    is then simply a matter of determining what subsequent lines will
    contain and what it will mean... then is would be quite simple to
    simply run thru and generate a SLF nodelist... GREP could surely
    do it and even SED could be used to cut off the POTS id field...
    if a node is ION or has some other connection method that keeps
    POTS and others from connecting directly, some sort of placeholder
    will have to reside in the POTS SLF nodelist for routing and such
    info (ie: some sort of gateway system)..

    yeah... I wonder if that would work, maybe the sendiing mailer would refuse
    to send the packets if it didn'r see an AKA from the anwering mailer that matcheds the address on the packets (you can see ther's a lot I don't know)

    it is much faster to read data directly from where you know it
    is to be rather than having to hunt it down... not only faster,
    but easier to code for, as well..

    and so we have domain names in the BBS-name field or in some
    flag... we can fix that tomorrow by adding more commas but what
    happens when something new happens.

    that's why i used blank commas... those fields use the existing
    data from the last line read... only the data that needs to be
    changed is put in... what that field is called doesn't really
    matter... it is the positioning that is important in that format
    for the fastest reading and processing..

    yeah... I guess you can use the flags to determine what sort of
    connection the line is describing, I was thinking of describing it
    explicitly with a new field

    There remains the question of system flags (flags that arent capability
    flags like " NEC ") do they go on all lines or are they autmatically
    duplicated somehow.

    different connection methods have different information
    requirements for dialup there's a phone number and a list of
    modem protocols and mailer capabilities, for interent there's an
    address (FQDN or IP) and a port number, and again mailer
    capabilities, a field with the bitrate may be handy too, for
    email attach I'm not sure what flags are needed, here bitrate is
    less critical, but maximum size may be useful.

    true and that is easily handled in two of the storage formats i've
    tossed out..

    if someone sets up fido via SMTP (a variation of via email?) or
    even via snail-mail they'll probably need still different
    fields...

    we can design this thing so that the politicians can't control
    it. so that new fields can be added without kludging them into
    flags

    I want to see a format that can handle any concievable method of
    moving fido mail... even sneakernet. - disk format(s), street
    address, contact name, room number, hours etc :)

    <<<GGG>>>> believe it or not, i know some systems that used to get
    <<<GGG>>>> their fidofix
    via snailmailed tapebackups..

    I've heard you can get usenet on cd-rom. didn't know fido was moved that way too.

    )\/(ark




    Bye <=-

    ---
    # Origin: I like work... I can sit and watch it for hours. (3:640/531.42)
    * Origin: Baddog BBS (1:218/903)
  • From mark lewis@1:218/903 to Jasen Betts on Wed Jul 17 19:27:44 2002
    Hmm, does anyone know what's an "RVIA" flag for and where is
    it documented?

    it is a failed experiment... it was started to store routing information in the

    nodelist... RVIA is Route VIA... there are additional ones, too... and no, i'm not sure where they ever were documented... they started as something tossed out in FTSC_PUBLIC (AIR) and a few jumped on it and added it to their nodelist entries as a userflag... userflags are experimental, right? in any case, others

    then jumped on that idea and added a method of scanning for those flags to generate netmail routing charts... sadly, none of those who fought (in Z1) about this even _use_ the information in their routing charts... the biggest idea was to try to get netmail routing as close to the hands of the destination

    system as possible rather than going on as had been where things just kinda flowed whichever way and the netmail might reach it's destination...

    )\/(ark


    * Origin: (1:3634/12)
    --- SBBSecho/Win32 v2.00
    * Origin: Baddog BBS (1:218/903)
  • From Frank Vest@1:218/903 to Jasen Betts on Wed Jul 17 22:04:26 2002
    On (16 Jul 02) Jasen Betts wrote to Frank Vest...

    Hello Jasen,

    Ok. Hang in there with me. I'll try to make this short (yeah,
    right :-)
    LOL... You've got me laughing.
    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. :)

    New Nodelist format (all on one line):
    1. The Node number. Well, duh, that's the prime thing, isn't it?
    Gotta have that.

    Yup.

    2. The system name. This is an "address book, after all. :)
    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.
    :-)

    3: The location of the system. Well, to generate an "old style" list,
    this is needed and is nice to know anyway.
    Yeah.
    4. The name of the operator of the system. Good to have since we are dealing with human beings here. :-)
    definitely essential

    5. The IP address or URL for DNS look up. 6. The "availability
    flags". I think these are pretty common in translation between
    Internet capable and POTS systems? 7. The Internet capability flags.
    yeah... gruping flags together like that makes sense

    Thank you.

    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

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

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

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

    10. Modem flags. If IP only, make something
    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...

    I have no idea on this. Some Guru that is better versed is needed.

    Ok. You can add all the bs you want after this. Why, I don't know.
    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.

    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.

    Now, make a program that will read this new list and spit out an
    old style list. The new list is formatted in such a way that the
    fields are set and clear. The program would read the new list and
    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)

    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"
    :-))

    IE: for an old style list, use fields 1,2,3,4,8,6,10,7 in that order.
    You could have it use field 5 for field 2 for the "proper" way to
    list an ION's IP address in the old style if desired. The "flags"
    would need to be separated by commas where the underscore is, but the 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...

    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.

    IMHO, No matter what we create; new Nodelist format, DNS look up
    or ???, it will be obsolete in time and require a "new way" to do
    it.
    The main thinh I want is a way that the new way can be introduced
    without compromising the functioning of existing nodes...

    Yes.

    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

    If the flag IBN, ITN or some other "I" flag exists, the node would be
    at least Internet capable.

    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.

    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.

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

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

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

    but that needn't be a bad thing, because the sysop can have a mailer
    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. :-)

    No matter what format we use; comma delimited, data base,
    magic wand or ???, the format will need to be changed in time to
    allow different protocols, communication methods and other
    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...

    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)
  • From Jasen Betts@1:218/903 to Frank Vest on Fri Jul 19 10:46:06 2002
    Hi Frank.

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

    yeah... gruping flags together like that makes sense

    Thank you.

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

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

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

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

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

    Possible, I guess. Although I had a 2400 baud modem that could do
    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)


    10. Modem flags. If IP only, make something
    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...

    I have no idea on this. Some Guru that is better versed is needed.

    Ok. You can add all the bs you want after this. Why, I don't know.
    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.

    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.

    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.

    Now, make a program that will read this new list and spit out an
    old style list. The new list is formatted in such a way that the
    fields are set and clear. The program would read the new list and
    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)

    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.

    IE: for an old style list, use fields 1,2,3,4,8,6,10,7 in that order.
    You could have it use field 5 for field 2 for the "proper" way to
    list an ION's IP address in the old style if desired. The "flags"
    would need to be separated by commas where the underscore is, but the
    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...

    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.

    huh?

    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.

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

    IMHO, No matter what we create; new Nodelist format, DNS look up
    or ???, it will be obsolete in time and require a "new way" to do
    it.
    The main thinh I want is a way that the new way can be introduced
    without compromising the functioning of existing nodes...

    Yes.

    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

    If the flag IBN, ITN or some other "I" flag exists, the node would be
    at least Internet capable.

    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.

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

    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.

    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.

    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,

    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.

    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.

    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.

    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)

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

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

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

    The old nodelist is generated from the new list. I'm not sure what you 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.

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

    I think that with the old nodelist being generated from the new list, 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)

    if the format is designed in the right way it can be made extendable
    without 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.

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

    Sorry for the long reply.

    bigger is better :)

    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)

    Bye <=-

    ---
    # Origin: "Qvid me anxivs svm?" (3:640/531.42)
    * Origin: Baddog BBS (1:218/903)
  • From Johannes Lundberg@1:218/903 to Frank Vest on Sat Jul 20 15:27:56 2002
    Fidonet just doesn't have the programmers that are willing to write a program that will handle a DNS, or other style, list and generate a Nodelist for the POTS systems that need it. Also, there would need to
    be programs to handle the DNS list. IE: mailers, and such.

    Programmers willing to spend time writing needed programs do exist. At least here in R20,Z2 (Sweden).


    * Origin: ... (2:206/149.13)
    --- SBBSecho/Win32 v2.00
    * Origin: Baddog BBS (1:218/903)
  • From Johannes Lundberg@1:218/903 to Peter Knapper on Sat Jul 20 15:46:10 2002
    it does not indicate what services are available and on
    what ports they reside.

    Ahhh, but it CAN, and even more, it can then allow the mapping of those services to the apprpriate place by using some external glue to handle it...

    I thought a bit of this. Using sub-domains for services/transport-protocols work quite well? IE, to find out if host 2:206/149 has binkp-access, you simply

    resolve 'binkp.f149.n206.z2.fidonet.net'. And to list the services available, you do a zone transfer on f149.n206.z2.fidonet.net. Port specification could be solved with a record looking like 'p4001.binkp.f149...'. The old BinkD @fidonet.net way would still work, as the f149-record would point to the right IP already. And new software developers would be instructed in using the new format.

    Comments?

    (This could also be done using a IN HINFO-record in the DNS, to avoid zone transfers)


    A feature being offered by some Dynamic DNS environments, links an HTTP URL to a persons home PC, however because that persons ISP prohibits them running an HTTP server on port 80, the DDNS reference for that web server points to what I will call a "port mapper", and that task automatically intercepts that Port 80 request and maps that to the customers real Web Server which is actually available on a different port.

    This is indeed quite nice, but if you don't want to modify the existing IP protocols (like BinkP), you will have a proxy forwarding all the traffic to the

    right IP. And this would probably require huge amounths of bandwidth on the proxy.

    Changing the existing protocols, and having the proxy just saying 'He is actually at IP 193.13.9.98, port 4001' would work. But in that case, I think it

    would be better to skip using DNS, and having our own noderesolver-server instead, who's prodiving the correct information from the beginning.


    * Origin: ... (2:206/149.13)
    --- SBBSecho/Win32 v2.00
    * Origin: Baddog BBS (1:218/903)
  • From Frank Vest@1:218/903 to Johannes Lundberg on Sat Jul 20 14:42:37 2002
    On (20 Jul 02) Johannes Lundberg wrote to Frank Vest...

    Hello Johannes,

    Fidonet just doesn't have the programmers that are willing to write a program that will handle a DNS, or other style, list and generate a Nodelist for the POTS systems that need it. Also, there would need to
    be programs to handle the DNS list. IE: mailers, and such.

    Programmers willing to spend time writing needed programs do exist. At least here in R20,Z2 (Sweden).

    True, but not in the numbers that Fidonet did have. New software to
    replace old software that is no longer developed is more difficult to
    find now.

    Maybe the real problem is that Fidonet has grown so used to having
    software "laid at their feet" that we have forgotten how, or just can
    not convince ourselves to ask someone to develop a software that is
    needed.

    Of course, not having standards and specifications to follow in the
    development is hurting development as well.


    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)
  • From Peter Knapper@1:218/903 to Johannes Lundberg on Sun Jul 21 10:41:36 2002
    Hi Johannes,

    I thought a bit of this. Using sub-domains for services/transport- protocols work quite well? IE, to find out if host
    2:206/149 has binkp-access, you simply resolve 'binkp.f149.n206.z2.fidonet.net'. And to list the
    services available, you do a zone transfer on
    f149.n206.z2.fidonet.net. Port specification could be
    solved with a record looking like 'p4001.binkp.f149...'.

    Yes, I think using current DNS services in a manner similar to the above is a perfectly viable way of getting Fidonet IP connectivity listed. The hard parts are -

    1. Getting everyone to agree on a common method of doing it within Fidonet, (IE build the STANDARDS that Fidonet will use for DNS records),

    2. Getting current code updated to use those standards.

    Changing the existing protocols, and having the proxy
    just saying 'He is actually at IP 193.13.9.98, port
    4001' would work. But in that case, I think it would be
    better to skip using DNS, and having our own
    noderesolver-server instead, who's prodiving the
    correct information from the beginning.

    Yes that is another way, however somewhere among all this we get back into the age old argument within Fidonet members that using a single service to manage such a task is putting all the eggs in one basket and taking the purpose for it

    being a hobby out of the hands of the users. Hence why distributing the info within DNS, rather than concentrating it in a few servers, makes good sense from several perspectives.

    Cheers..............pk.

    --- Maximus/2 3.01
    # Origin: Another Good Point About OS/2 (3:772/1.10)
    * Origin: Baddog BBS (1:218/903)
  • From Johannes Lundberg@1:218/903 to Frank Vest on Sun Jul 21 15:41:07 2002
    Maybe the real problem is that Fidonet has grown so used to having software "laid at their feet" that we have forgotten how, or just can
    not convince ourselves to ask someone to develop a software that is needed.

    Might be so. I'm there in some aspects myself.

    Of course, not having standards and specifications to follow in the development is hurting development as well.

    True, and that's one of the problems I think we should try to solve here.


    * Origin: ... (2:206/149.13)
    --- SBBSecho/Win32 v2.00
    * Origin: Baddog BBS (1:218/903)
  • From Johannes Lundberg@1:218/903 to Peter Knapper on Sun Jul 21 18:59:49 2002
    Yes that is another way, however somewhere among all this we get back
    into the age old argument within Fidonet members that using a single service to manage such a task is putting all the eggs in one basket and taking the purpose for it being a hobby out of the hands of the users. Hence why distributing the info within DNS, rather than concentrating it in a few servers, makes good sense from several perspectives.

    Relying on one single server is not very good. Especially not if ALL mail-transfers depends on it. That's one potential problem using such a system (as the DNS-system, or a system of our own). If the "root"-server (the DNS-server for the domain, like fidonet.net) goes down, not a single conversion

    from 4D-adress to IP and Services can be done during the downtime.


    * Origin: ... (2:206/149.13)
    --- SBBSecho/Win32 v2.00
    * Origin: Baddog BBS (1:218/903)
  • From Frank Vest@1:218/903 to Johannes Lundberg on Sun Jul 21 20:25:04 2002
    On (21 Jul 02) Johannes Lundberg wrote to Frank Vest...

    Hello Johannes,


    Maybe the real problem is that Fidonet has grown so used to having software "laid at their feet" that we have forgotten how, or just can
    not convince ourselves to ask someone to develop a software that is needed.
    Might be so. I'm there in some aspects myself.

    I hope my Netmail to you arrives. :)

    Of course, not having standards and specifications to follow in the development is hurting development as well.
    True, and that's one of the problems I think we should try to solve
    here.

    A new format to the Nodelist would be a new standard in a way.


    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)
  • From Jasen Betts@1:218/903 to Peter Knapper on Mon Jul 22 07:42:06 2002
    Hi Peter.

    21-Jul-02 08:41:36, Peter Knapper wrote to Johannes Lundberg


    Yes that is another way, however somewhere among all this we get
    back into the age old argument within Fidonet members that using a
    single service to manage such a task is putting all the eggs in
    one basket and taking the purpose for it being a hobby out of the
    hands of the users. Hence why distributing the info within DNS,
    rather than concentrating it in a few servers, makes good sense
    from several perspectives

    yeah, BIND 9 was just announced last week.
    BIND = Berkley Internet Name Daemon, it's a free (no charge, open source)
    DNS, with all sorts of neat featrures, from the peouple at UCB (Unversity of California, Berkley).
    So pretty much any linux system (or BSD) can put up a cutting edge DNS service...

    Bye <=-

    ---
    # Origin: Be different: conform. (3:640/531.42)
    * Origin: Baddog BBS (1:218/903)
  • From mark lewis@1:218/903 to Jasen Betts on Mon Jul 22 20:45:24 2002
    no it's not. relational databases don't have such limitations.

    they do, however, have specific fields in the tables and that data
    is stored in a specific place in the stream data... to me,
    relational databases are just that... databases of data that is
    linked together via some piece of info common in them... what folk
    see today as a table, i grew up with knowing is as a database...
    making the switch from a database to many linked via a piece of
    data between them was very easy for me... another term would be
    database of databases <<GG>

    once you go ro 5NF every filed is optional or may be repeated
    ^^^^^^
    hunh???

    any numbrer of times (except the key field)...

    [trim]

    not sure of the reference... i was thinking of keeping the POTS
    data the same and building from there..

    why keep pots?

    why eliminate existing technology? what would be done if something happened to the internet and it collapsed? POTS will still be around for many years to come...

    [trim]

    why have to add field identifiers and then have to create
    "smart" programs that have to be able to pick out the data they
    need no matter what order it is in?

    why not, it's not exaclty hard, if we're smart we'll be able to
    co-opt some freeware SGML or XML (etc) parsing library to the
    task (LGPL allows use if the library in commercial code)

    understood but why? what is wrong with using a fixed format that
    is extensible?

    that's what I was proposing :)

    that's confusing... a fixed format that has floating field positions... seems more like an oxymoron...

    heck, we could code some sort of comma-encoding to
    show number of empty comma fields is that is a problem..

    I'd prefer to make them optional.

    then you loose the placeholders... they are needed if they are the first row for that entry, too...

    sure, we could code up some relational database FDNS and
    import/update the POTS data and have additional tables named for
    the functions served... POTS table, FTP table, IBN table, etc...
    that database would be easily extensible except for the fact that
    not all systems would have access and not all future system may
    have access to the internet as we know it today... it is, however,
    not much different from my proposal that we add another field to
    the front of the SLF nodelist to designate that line's use... it
    is then simply a matter of determining what subsequent lines will
    contain and what it will mean... then is would be quite simple to
    simply run thru and generate a SLF nodelist... GREP could surely
    do it and even SED could be used to cut off the POTS id field...
    if a node is ION or has some other connection method that keeps
    POTS and others from connecting directly, some sort of placeholder
    will have to reside in the POTS SLF nodelist for routing and such
    info (ie: some sort of gateway system)..

    yeah... I wonder if that would work, maybe the sendiing mailer
    would refuse to send the packets if it didn'r see an AKA from
    the anwering mailer that matcheds the address on the packets
    (you can see ther's a lot I don't know)

    that's actually a normal part of fido mailer communications... the nodelist doesn't even come into play at that point...

    it is much faster to read data directly from where you know it
    is to be rather than having to hunt it down... not only faster,
    but easier to code for, as well..

    and so we have domain names in the BBS-name field or in some
    flag... we can fix that tomorrow by adding more commas but what
    happens when something new happens.

    that's why i used blank commas... those fields use the existing
    data from the last line read... only the data that needs to be
    changed is put in... what that field is called doesn't really
    matter... it is the positioning that is important in that format
    for the fastest reading and processing..

    yeah... I guess you can use the flags to determine what sort
    of connection the line is describing, I was thinking of
    describing it explicitly with a new field

    that's true... but i do rather kinda like my idea of adding a leading field that contains the connection type that the row refers to... that would also make it hugely easier to create oldstyle nodelist that contain just POTS info or IP info only...

    There remains the question of system flags (flags that arent
    capability flags like " NEC ") do they go on all lines or are
    they autmatically duplicated somehow.

    automatically carried just like the rest of the data... its a "trickle down" type flow... if there are 10 fields in the first row and the second row only has data in fields 5 and 9 then those are the only two fields changed in the row generated from the data in the first row...

    [trim]

    I want to see a format that can handle any concievable method of
    moving fido mail... even sneakernet. - disk format(s), street
    address, contact name, room number, hours etc :)

    <<<GGG>>>> believe it or not, i know some systems that used
    to get their fidofix via snailmailed tapebackups..

    I've heard you can get usenet on cd-rom. didn't know fido
    was moved that way too.

    fidonet has been moved via many different methods... afterall, the only goal is

    to get the PKTs from one system to another... HOW they move isn't really that important unless it is via direct communications between the originator and the

    destination... HAM/ShortWave radio, sneakernet, infrared laser, fiberoptic, FM radio broadcast, snailmail, DAT tape, QIC tape, VHS tape, morse code, and i'm sure that there are many other means...

    )\/(ark


    * Origin: (1:3634/12)
    --- SBBSecho/Win32 v2.00
    * Origin: Baddog BBS (1:218/903)
  • From mark lewis@1:218/903 to Frank Vest on Tue Jul 23 00:01:00 2002
    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

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

    yup...

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

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

    thank you...

    10. Modem flags. If IP only, make something
    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...

    I have no idea on this. Some Guru that is better versed is
    needed.

    modem capability flags are needed IF there is a modem answering the line... if it is telnet or some other network protocol, then other flags may be needed but

    not modem flags... unless we develop some "dual meaning" flags... one thing if modem, another if a certain network protocol...

    Ok. You can add all the bs you want after this. Why, I
    don't know. 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.

    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.

    the thing to remember here is that the flags after the speed field are all grouped together as a(nother) comma seperated field... and it is possible (of course) to have an additional comma seperated field in there known as U(ser) flags...

    Now, make a program that will read this new list and
    spit out an old style list. The new list is formatted
    in such a way that the fields are set and clear. The
    program would read the new list and 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)

    User flags seem useless to me in most respects.

    userflags were inteneded to be for testing of new flags... if they became widespread in use, they were to be upgraded to "normal" flags...

    I often laugh at the thought of putting a user flag in
    like "U,I'm_the"biggest_stud_in_Fidonet_Prove_me_wrong"
    :-))

    yes, but that one shouldn't be allowed by the *C processing that segment because it is frivilous and doesn't serve any technical function(s)...

    [trim]

    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.

    uggg... that leave too much open to go wrong... someone could adjust that line in the config file and then that row or entire segment might be dropped by the processing software due to something being invalid...

    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.

    right...

    [trim]

    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

    If the flag IBN, ITN or some other "I" flag exists, the
    node would be at least Internet capable.

    that might be possible but it could also be restricting in the future... better

    to have a complete new field similar to my proposal of an additional leading field containing the connection type for the row...

    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.

    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.

    my proposal doesn't need to get that detailed... its quite simple... if there is a POTS field, then there is POTS capability and that POTS row contains the data to use for a POTS connection... if there is an IP field, then there is IP capability and that IP row, blended with the POTS row, contains the data to be used for an IP connection... if there is no POTS row, then the IP row contains all the needed data... same goes with a row that contains an (as yet uninvented) LASER field for some futuristic lightbeam methodology or even SUBSPACE42 for communication on subspace channel 42 or the like...

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

    i don't agree... we are doing a new list format simply because the old SLF doesn't cover today's needed options...

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

    the flags are grouped together... they just happen to consist of possibly two comma delimited lists of flags in any order...

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

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

    take a POTS system converting the new style list to an old style list... he's thinking of how would a IP or IPonly system be listed... i say it doesn't really matter... it is either listed as PVT unpublished (for software that insists on verification in the list before allowing message creation or contact) or it is skipped altogether is fido systems become more like internet systems in that they use "smarthosts"... in other words, it doesn't matter what

    system you are sending mail to, just create it and send it to your smarthost...

    if it cannot determine where to send it next and bounces it back to you, ok then... internet UUCP and even today's email all works like this...

    but that needn't be a bad thing, because the sysop can
    have a mailer 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. :-)

    maybe... once all the logistics are worked out and a firm set of rules are put in place... once that happens, then a hardcoded util can be written to do the job...

    No matter what format we use; comma delimited, data base,
    magic wand or ???, the format will need to be changed in
    time to allow different protocols, communication methods
    and other 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...

    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.

    i don't know that i can agree completely with the first line... as long as a POTS node remains in fidonet, there will be field that others will not use... as for the grouping, remember, this is a technical network... it is very easy for me, as a programmers, to write a program that reads a line of test and seperates it into 8 fields with the last field containing additional comma seperated fields... remember also, the nodelist was not formatted for human consumption... it was formatted for machine comsumption and anything one tried to do that wasn't in the nodelist, the software that interfaced would let the human know about... all we're supposed to do is communicate...

    )\/(ark


    * Origin: (1:3634/12)
    --- SBBSecho/Win32 v2.00
    * Origin: Baddog BBS (1:218/903)
  • From mark lewis@1:218/903 to Jasen Betts on Tue Jul 23 01:25:38 2002
    yeah... gruping flags together like that makes sense

    Thank you.

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

    <<GG>>

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

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

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

    thus the format of my (second) proposal...

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

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

    Hmm, there's no V22B flag for 2400 bps modems.
    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...

    (did they produce any MNP ot V42 modems incapable
    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]

    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.

    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.

    true, if one is adding fields to the end of the row...

    [trim]

    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.

    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]

    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.

    yeah, there's no way to extraact a system named from a
    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]

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

    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.

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

    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.

    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.

    my (2nd) proposal allows for just this... the 1st one does too but it's harder to add additional capabilities to...

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

    why not just put the indicator at the beginning of the row and "meld" the info that is the same from the previous lines??

    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.

    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.

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

    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.

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

    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

    still have some problems with this format, i'm positive... however, i cannot think of anything other than linelength parsing at the moment...

    POTS and ISDN could be combined but it's hard to pick which
    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...

    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)

    i disagree with the initial portion... _developers_ would set up the rulesets... the users may select the rulesets their systems can handle...

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

    grouping it makes it easier to scan in some languages (you
    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)
  • From mark lewis@1:218/903 to Frank Vest on Tue Jul 23 01:49:54 2002
    True, but not in the numbers that Fidonet did have. New
    software to replace old software that is no longer
    developed is more difficult to find now.

    Maybe the real problem is that Fidonet has grown so used
    to having software "laid at their feet" that we have
    forgotten how, or just can not convince ourselves to ask
    someone to develop a software that is needed.

    ummm... this is what happens when politicos take over and those with the technical prowness leave...

    Of course, not having standards and specifications to
    follow in the development is hurting development as well.

    ummm... there are standards... only seven (original) FTS documents, AIR... all the rest are proposals... well, before the current FTSC was formed and subsequently fell asleep like the original one...

    )\/(ark


    * Origin: (1:3634/12)
    --- SBBSecho/Win32 v2.00
    * Origin: Baddog BBS (1:218/903)
  • From Peter Knapper@1:218/903 to Jasen Betts on Tue Jul 23 21:28:04 2002
    Hi Jasen,

    yeah, BIND 9 was just announced last week.
    BIND = Berkley Internet Name Daemon, it's a free (no charge, open source) DNS, with all sorts of neat featrures, from the peouple
    at UCB (Unversity ofCalifornia, Berkley).
    So pretty much any linux system (or BSD) can put up a cutting edge DNS service...

    And OS/2 as well of course, I am already running OS/2 Bind V8.1 as a Caching DNS under W4 FP15 with IP v4.1.....;-)

    Cheers.......................pk.


    --- Maximus/2 3.01
    # Origin: Another Good Point About OS/2 (3:772/1.10)
    * Origin: Baddog BBS (1:218/903)
  • From Jasen Betts@1:218/903 to mark lewis on Wed Jul 24 13:32:14 2002
    Hi mark.

    a piece of data between them was very easy for me... another
    term would be database of databases <<GG>

    once you go ro 5NF every filed is optional or may be repeated
    ^^^^^^ hunh???
    any numbrer of times (except the key field)...

    To fifth normal form (might be fourth normal form), It's been a while since
    I studued that stuff...

    not sure of the reference... i was thinking of keeping the POTS
    data the same and building from there..

    why keep pots?

    why eliminate existing technology? what would be done if something happened to the internet and it collapsed? POTS will still be
    around for many years to come..

    What I meant was why keep pots in all the records when a large number of
    nodes don't use it.

    why not, it's not exaclty hard, if we're smart we'll be able to
    co-opt some freeware SGML or XML (etc) parsing library to the
    task (LGPL allows use if the library in commercial code)

    understood but why? what is wrong with using a fixed format that
    is extensible?

    why noty use the extensions to reduce size of the fixed component to the essentials.

    then you loose the placeholders... they are needed if they are the
    first row for that entry, too..

    what I meant was by putting POTS into the extension there's no need for
    empty fields, on non-pots systems.

    that's actually a normal part of fido mailer communications...

    That's good.

    that's true... but i do rather kinda like my idea of adding a
    leading field that contains the connection type that the row
    refers to... that would also make it hugely easier to create
    oldstyle nodelist that contain just POTS info or IP info only..

    The type flag would make the softwar emuch easier to write, and yeah the program could probably be written fairly easily.

    There remains the question of system flags (flags that arent
    capability flags like " NEC ") do they go on all lines or are
    they autmatically duplicated somehow.

    automatically carried just like the rest of the data... its a
    "trickle down" type flow... if there are 10 fields in the first
    row and the second row only has data in fields 5 and 9 then those
    are the only two fields changed in the row generated from the data
    in the first row..

    if is there's a flag on the first row that you don't want on the second
    row, what do you do... put it last on the fisrs row and use fewer commas on
    the second row? (could work but could trap many programmers)

    I want to see a format that can handle any concievable method
    of moving fido mail... even sneakernet. - disk format(s),
    street address, contact name, room number, hours etc :)

    <<<GGG>>>> believe it or not, i know some systems that used to
    get their fidofix via snailmailed tapebackups..

    My boss node just admitted that he carries echomail accross the room on a floppy disk, from his internet machine to the BBS. He's going on a
    motorbike trip so I the flow may bet a bit lumpy as Hell only b able to
    poll his uplink where He can find somewhere to plug his laptop in..

    fidonet has been moved via many different methods...

    radio broadcast, snailmail, DAT tape, QIC tape, VHS tape, morse
    code, and i'm sure that there are many other means..

    Some jokers invented IP via carrier pidgeon, and it was tested
    and found to work, throughput wasn't real impressive though.
    if you're interested I'll try and dig up the RFC number.

    Bye <=-
    ---
    # Origin: Every absurdity has a champion who will defend it. (3:640/531.42)
    * Origin: Baddog BBS (1:218/903)
  • From Jasen Betts@1:218/903 to mark lewis on Wed Jul 24 14:07:50 2002
    Hi mark.

    22-Jul-02 22:01:00, mark lewis wrote to Frank Vest

    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.

    i don't know that i can agree completely with the first line...

    Frank wants to dedicate the fields to specific purposes this means
    clumping the flags together into a fixed number of fileds.

    It's a slightly more radical change from the existing nodelist format than
    your proposal, but it would allow the each node to list all their information on a single line (because the meahing of each filed would be fixed)

    eg (from memory)

    title,num,who,what,where,flags,type1,addr1,flags1,type2,addr2,flags2
    ------------------ ------------------

    With any number of type-addr-flags triples
    (none for an uncontactable node)

    as long as a POTS node remains in fidonet, there will be field that
    others will not use...

    Only if you make the POTS fields compulsory...
    I propose using the connection type field to determine the meaning of the
    addr (phone number/ip address/ etc) field

    as for the grouping, remember, this is a technical network... it is
    very easy for me, as a programmers, to write a program that reads a
    line of test and seperates it into 8 fields with the last field
    containing additional comma seperated fields...

    To me it seems easier It's easier to loop re-reading fields three at a time until you dit end-of-line,rather than remembering all the fileds from the previous line and copying them into the blank fileds of this line, and not copying them after the last blank field on this line etc...

    some questions about your proposal illustrating the complexities i see
    hidden in the simple concept:
    do all the fields reset if you put a new node number in
    does the first field copy to following lines like other fields do
    are there other special cases in your format?

    personally I think the Idea frank and I are discussing proposing is less complex, because I feel we've eliminated all the exceptions to the rules ...

    I don't feel that ease of conversion is worth pursuing to the extent that
    the nodelist remains full of special cases, and in-fact gains more.

    Bye <=-
    ---
    # Origin: Never call a man a fool. Borrow from him. (3:640/531.42)
    * Origin: Baddog BBS (1:218/903)
  • From Jasen Betts@1:218/903 to mark lewis on Wed Jul 24 14:45:11 2002
    Hi mark.

    nope... the MNP flag means one thing... V42 means another... in
    fact, as i recall, V42 was a speed and V42B is/was error
    correction

    I think V42 is eror recovery and V42B is compression as well as error
    recovery. V42 also implies MNP level 4 (because V42 is compatible with MNP levels 1 to 4)

    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.

    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>

    :) I know a little machine code, but usually I use an assembler.

    [snip]

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


    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.


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

    Hub,200,NY_Capital_Hub,Greater_Capital_District,Gregory_Deyss,1-000-000-0000,
    33600,CM,XA,V32b,V42b,V34,IFT,ITX

    If you're to believe Gregorys flags, you can contact this node via IP or
    modem but he doesn't publish a domain name, IP address, or phone number :)

    Or am I reading it wrong? :)

    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.

    my (2nd) proposal allows for just this... the 1st one does too but
    it's harder to add additional capabilities to..

    yeah, I disagree abot ease of programming though.


    i intended the follling paragraphs to represent single lines in the
    new nodelist, I just wrapped them to make them easier to read

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

    ,1701,Some_BBS_Name,Some_Town,Some_Sysop,system_flags,
    POTS,<phone number>,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

    why not just put the indicator at the beginning of the row and
    "meld" the info that is the same from the previous lines?

    because I got tired of typing "(all on one line)" and assume that everyone would assume it... (ani thusly made an ass of me atleast), I deal with what
    I think you're asking in a few paragraphs, read on.

    I also forgot to say that for an uncontactable node it's be somethin like

    ,1701,Some_BBS_Name,Some_Town,Some_Sysop,system_flags

    (no dummy connection with a blank or "-Unpublished-" etc...)


    however you do have a point, (of the sharp type)

    My (badly specified) one-line format format could be changed to a multi
    line format like your #2 by spltting off the second and subsequent connections and adding blank fields to the start of them (and reordering some of the fields)

    the reasons why I don't like that is because it's full of exceptions, exceptions cause code complexity, and code complexity often causes bugs.

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

    Yeah it's pretty much functionally equivalent to my proposal.

    uh, you still have to read the list a line at the time...

    you can _read_ it a character at a time if you want....

    some things need to be done a node at a time (eg converting to SLF),
    but you could still handle the data a connection at time...

    IMO reading the nodleist a line aat a time is a bad idea, (especially my proposal)

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

    255?, that short? why?

    GWbasic and Turbo pascal are dead languages. most other langauises don't
    have such restrictive string lenght limits.

    IMO 255 might be a good field length limit...

    for conversion the converter may need to be designed to trim non-essential fields (like location, system name etc)to keep the lines short enough.

    still have some problems with this format, i'm positive...
    however, i cannot think of anything other than linelength parsing
    at the moment..

    yeah 255 is pretty cramped, way too short for my proposal.

    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)

    i disagree with the initial portion... _developers_ would set up
    the rulesets... the users may select the rulesets their systems
    can handle..

    yeah, that's true, once a rulset is made for mailer brand X version N it should be distributed with the conversion tool, forcing users to deveop
    their own software is a bad thing.

    Probably fewer than 10 rulesets would suffice for 99% of fidonet

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

    agreed but then coding for this stuff wouldn't be much "fun"
    <<wink>>

    using the software's supposed to be fun, writing it is supposed to be easy,
    as is modifying it :)

    Bye <=-
    ---
    # Origin: Only adults have difficulty with childproof caps. (3:640/531.42)
    * Origin: Baddog BBS (1:218/903)
  • From mark lewis@1:218/903 to Jasen Betts on Wed Jul 24 18:33:46 2002
    a piece of data between them was very easy for me... another
    term would be database of databases <<GG>

    once you go ro 5NF every filed is optional or may be repeated
    ^^^^^^ hunh???
    any numbrer of times (except the key field)...

    To fifth normal form (might be fourth normal form), It's been
    a while since I studued that stuff...

    oh... can't say that i've ever heard the term...

    not sure of the reference... i was thinking of keeping
    the POTS data the same and building from there..

    why keep pots?

    why eliminate existing technology? what would be done if
    something happened to the internet and it collapsed? POTS
    will still be around for many years to come..

    What I meant was why keep pots in all the records when a
    large number of nodes don't use it.

    ya don't! the first line contains all the data necessary for the node information... if the node has no POTS capabilities, then there is no POTS row... i was just starting all my examples with POTS and then putting in the deviations after but the entries for a node could surely have a IP row first and then the POTS next...

    why not, it's not exaclty hard, if we're smart we'll be
    able to co-opt some freeware SGML or XML (etc) parsing
    library to the task (LGPL allows use if the library in
    commercial code)

    understood but why? what is wrong with using a fixed
    format that is extensible?

    why noty use the extensions to reduce size of the fixed
    component to the essentials.

    i just see no need to go to that level... plain ASCII text is fine and we don't

    really need to go adding <TAG></TAG>'s to everything, do we?

    then you loose the placeholders... they are needed if
    they are the first row for that entry, too..

    what I meant was by putting POTS into the extension
    there's no need for empty fields, on non-pots systems.

    won't be any empty fields, i don't believe...

    that's actually a normal part of fido mailer
    communications...

    That's good.

    that's true... but i do rather kinda like my idea of adding a
    leading field that contains the connection type that the row
    refers to... that would also make it hugely easier to create
    oldstyle nodelist that contain just POTS info or IP info only..

    The type flag would make the softwar emuch easier to write,
    and yeah the program could probably be written fairly easily.

    yup and with hardcoded settings for those nodes that don't carry needed info...

    There remains the question of system flags (flags that arent
    capability flags like " NEC ") do they go on all lines or are
    they autmatically duplicated somehow.

    automatically carried just like the rest of the data... its a
    "trickle down" type flow... if there are 10 fields in the first
    row and the second row only has data in fields 5 and 9 then those
    are the only two fields changed in the row generated from the data
    in the first row..

    if is there's a flag on the first row that you don't want on
    the second row, what do you do...

    redefine that flag sequence on the subsequent row(s)

    put it last on the fisrs row and use fewer commas on
    the second row? (could work but could trap many programmers)

    no, the flags section is a comma seperated list just like the row... kinda like

    an OOP object as a data item in another OOP object...

    I want to see a format that can handle any concievable method
    of moving fido mail... even sneakernet. - disk format(s),
    street address, contact name, room number, hours etc :)

    <<<GGG>>>> believe it or not, i know some systems that used to
    get their fidofix via snailmailed tapebackups..

    My boss node just admitted that he carries echomail accross
    the room on a floppy disk, from his internet machine to the
    BBS. He's going on a motorbike trip so I the flow may bet a
    bit lumpy as Hell only b able to poll his uplink where He
    can find somewhere to plug his laptop in..

    hehe... yup, sneakernetting has been done for many many years and most don't even know they are doing it <<GG>>

    fidonet has been moved via many different methods...

    radio broadcast, snailmail, DAT tape, QIC tape, VHS tape, morse
    code, and i'm sure that there are many other means..

    Some jokers invented IP via carrier pidgeon, and it was tested
    and found to work, throughput wasn't real impressive though.
    if you're interested I'll try and dig up the RFC number.

    hahahahahahahaha... i've seen it! now that's a memory! throughput? what's that?

    the data gets to the destination, right? hehehehehehe...

    )\/(ark


    * Origin: (1:3634/12)
    --- SBBSecho/Win32 v2.00
    * Origin: Baddog BBS (1:218/903)
  • From mark lewis@1:218/903 to Jasen Betts on Wed Jul 24 18:57:34 2002
    nope... the MNP flag means one thing... V42 means
    another... in fact, as i recall, V42 was a speed
    and V42B is/was error correction

    I think V42 is eror recovery and V42B is compression
    as well as error recovery.

    nope... its only one or the other... that was one of the first confusing flags i've run into...

    [trim]

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

    Hub,200,NY_Capital_Hub,Greate r_Capital_District,Gregory_Deyss,1-000-000-0000,
    33600,CM,XA,V32b,V42b,V34,IFT,ITX

    If you're to believe Gregorys flags, you can contact this node
    via IP or modem but he doesn't publish a domain name, IP
    address, or phone number :)

    Or am I reading it wrong? :)

    you are not reading it wrong... and its not who i was thinking it may have been...

    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.

    my (2nd) proposal allows for just this... the 1st one does too but
    it's harder to add additional capabilities to..

    yeah, I disagree abot ease of programming though.

    i dunno... i'm visualizing the flow in pascal (actually)... i'm just seeing the

    first row filled and then the reading of the next line and parsing it for each field just not being that hard... and then to overlay the changed fields on the

    old, no biggie... kinda like using a buffer to store the data in and then using

    different structures that are overlaid right on top of that buffer... gosh, what is/was the term used for that?

    [time passes]

    the definition in PASCAL would be like this (taken from one of my PKT analysis programs)

    var
    bheader : bulkheader;
    header1 : pkthead1 absolute bheader;
    header2 : pkthead2 absolute bheader;
    header3 : pkthead3 absolute bheader;

    that's just the variables that one works with... the actual structures were defined in the TYPE section... bulkheader was simply defined as an array[1..58]

    of byte...

    i intended the follling paragraphs to represent single
    lines in the new nodelist, I just wrapped them to make
    them easier to read

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

    ,1701,Some_BBS_Name,Some_Town,Some_Sysop,system_flags,
    POTS,<phone number>,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

    understand but also hear others "screaming" about the "bulkiness" and duplication of the data... that has always been a bitch... "the nodelist is too

    large. why can't we cut it down in physical size?"

    why not just put the indicator at the beginning of the row and
    "meld" the info that is the same from the previous lines?

    because I got tired of typing "(all on one line)" and assume
    that everyone would assume it... (ani thusly made an ass of
    me atleast), I deal with what I think you're asking in a few
    paragraphs, read on.

    'k...

    I also forgot to say that for an uncontactable node it's be
    somethin like

    ,1701,Some_BBS_Name,Some_Town,Some_Sysop,system_flags

    (no dummy connection with a blank or "-Unpublished-" etc...)


    however you do have a point, (of the sharp type)

    My (badly specified) one-line format format could be changed
    to a multi line format like your #2 by spltting off the
    second and subsequent connections and adding blank fields to
    the start of them (and reordering some of the fields)

    the reasons why I don't like that is because it's full of
    exceptions, exceptions cause code complexity, and code
    complexity often causes bugs.

    i see that you came to the same conclusions i did and by kinda the same methods

    that i did...

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

    Yeah it's pretty much functionally equivalent to my proposal.

    kinda...

    uh, you still have to read the list a line at the time...

    you can _read_ it a character at a time if you want....

    true but it'll still build out to be a line once you get to the line terminator...

    some things need to be done a node at a time (eg converting to
    SLF), but you could still handle the data a connection at time...

    IMO reading the nodleist a line aat a time is a bad idea,
    (especially my proposal)

    that's pretty much how most nodelist processors do it...

    readln(infile,linebuff);
    [determine if line is to be copied to output]
    [ if yes, then]
    listcrc := updatecrc(linebuff);
    [ else ]
    [loop to top and get next line]

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

    255?, that short? why?

    ummm, turbo pascal is still used by many newbie (and long time) developers... not to mention that there are even bbs message base formats built on that particular limit... the HMB MSGTXT.BBS file is one such... nothing but rows of strings...

    GWbasic and Turbo pascal are dead languages. most other
    langauises don't have such restrictive string lenght limits.

    while TP might be "dead" is it still in widespread use... in fact, i'm personally aware of several bbs packages and related products that are produced

    with TP... some even as old as TP 5.0...

    IMO 255 might be a good field length limit...

    for conversion the converter may need to be designed to trim
    non-essential fields (like location, system name etc)to keep
    the lines short enough.

    still have some problems with this format, i'm positive...
    however, i cannot think of anything other than linelength parsing
    at the moment..

    yeah 255 is pretty cramped, way too short for my proposal.

    and too short for my single line proposal, too... that's one of the main reasons why i looked to the multiline proposal...

    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)

    i disagree with the initial portion... _developers_ would set up
    the rulesets... the users may select the rulesets their systems
    can handle..

    yeah, that's true, once a rulset is made for mailer brand X
    version N it should be distributed with the conversion tool,
    forcing users to deveop their own software is a bad thing.

    Probably fewer than 10 rulesets would suffice for 99% of
    fidonet

    agreed... and my thoughts are that they'd likely be coded in the program and this reside in the .EXE (to use dos think for a moment)...

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

    agreed but then coding for this stuff wouldn't be much "fun"
    <<wink>>

    using the software's supposed to be fun, writing it is
    supposed to be easy, as is modifying it :)

    hehehe, i can see that you didn't graduate from the same school as i did <<GG>>

    i actually enjoy coding... well, did a lot more some years ago until major burnout caused me to have to step back for many months...

    )\/(ark


    * Origin: (1:3634/12)
    --- SBBSecho/Win32 v2.00
    * Origin: Baddog BBS (1:218/903)
  • From Goran Eriksson@1:218/903 to Haakan Karlsson on Wed Jul 24 21:00:48 2002
    Secondly, how would you convert a zone or region independent entry
    that doesn't announce any POTS capability?

    I don't recognize the problem, maybe I am overlooking something in
    how the nodelist works.

    Converting such a node to a Pvt listing might cause problems.

    FTS-5000 says:

    Pvt --
    Defines a private node with unlisted number. Private nodes
    are only allowed as members of local networks.

    Even my oldest copy of the FidoNet nodelist specification (FSC-2 dated 1988-01-02) has an identical requirement. (I would appreciate pointers to any other versions of FSC-2, other versions of FTS-2 than 1988-11-06 and/or other versions of FTS-5 than 1989-02-05, 1996-06-01 and 2001-01-03.)

    I've not been able to find any explicit, trustworthy and contemporary motivation for this requirement, but I'm speculating as follows:

    The only ones required by administrative FidoNet policy to offer inbound netmail routing are the network hosts. (I know that many ZC's, RC's and hubs do

    the same, but that's another thing.) Therefore putting a Pvt node outside a local network (e.g. as region or zone independents) would mean that there is noone who is required (by policy) to forward netmail to that node.

    In any case, MakeNl vigorously enforces this restriction and therefore I wouldn't be surprised if some other nodelist processing tool also rejects such nodes. Furthermore, it would be nice to have the 'old style' nodelist so compatible with MakeNl that MakeNl can be used to recreate a missing nodediff from two 'old style' nodelists created by the sort of conversion programs that has been discussed here.


    ---
    # Origin: GET, Lulea, Sweden, +46-920-257910 (2:201/505.1)
    * Origin: Baddog BBS (1:218/903)
  • From Jasen Betts@1:218/903 to mark lewis on Fri Jul 26 10:49:41 2002
    why noty use the extensions to reduce size of the fixed component
    to the essentials.

    i just see no need to go to that level... plain ASCII text is fine
    and we don't really need to go adding <TAG></TAG>'s to everything,
    do we

    I was just describing my proposal.... with 6 fixed fileds and then 3*n
    optional fileds... each 3 fileds describing a connection method,
    I wasn't suggesting XML style tags... I 've given up on them.

    then you loose the placeholders... they are needed if they are
    the first row for that entry, too..

    what I meant was by putting POTS into the extension there's no
    need for empty fields, on non-pots systems.

    won't be any empty fields, i don't believe...

    how do you represent a private node?

    if is there's a flag on the first row that you don't want on the
    second row, what do you do...

    redefine that flag sequence on the subsequent row(s)

    huh?

    put it last on the fisrs row and use fewer commas on the second
    row? (could work but could trap many programmers)

    no, the flags section is a comma seperated list just like the
    row... kinda like an OOP object as a data item in another OOP
    object..

    huh? do you mean the flags section is treated like a single field?
    so if there are any flags on a line all the flags from the line above are ingnored for the current line?

    Bye <=-

    ---
    # Origin: Every solution breeds new problems. (3:640/531.42)
    * Origin: Baddog BBS (1:218/903)
  • From Jasen Betts@1:218/903 to mark lewis on Fri Jul 26 10:58:29 2002
    Hi mark.

    24-Jul-02 16:57:34, mark lewis wrote to Jasen Betts


    nope... the MNP flag means one thing... V42 means another... in
    fact, as i recall, V42 was a speed and V42B is/was error
    correction

    I think V42 is eror recovery and V42B is compression as well as
    error recovery.

    nope... its only one or the other... that was one of the first
    confusing flags i've run into..

    AH, I was describing CCITT protocols, you were describibing flags with
    similar names. ir makes sense that old software wouldn't know that V42b
    implies V42. (according to CCITT) so the fido docs say you should indicate
    both if if you do V42b.

    i dunno... i'm visualizing the flow in pascal (actually)... i'm
    just seeing the first row filled and then the reading of the next
    line and parsing it for each field just not being that hard... and
    then to overlay the changed fields on the old, no biggie... kinda
    like using a buffer to store the data in and then using different structures that are overlaid right on top of that buffer... gosh,
    what is/was the term used for that

    [time passes]

    pkthead1 absolute bheader;

    You can't just "absolute" them over each other because then reading one
    would erase the next...

    understand but also hear others "screaming" about the "bulkiness"
    and duplication of the data... that has always been a bitch...
    "the nodelist is too large. why can't we cut it down in physical
    size?

    size doesn't really worry me... sure whn it was 3 megs it took about 20% of
    my hard space to edit it (for a friend with an amiga who didn't have enough
    ram - neither did I but wordstar doesn't need big ram to edit a big file)

    true but it'll still build out to be a line once you get to the
    line terminator..

    depends how you code the reading...

    255?, that short? why?

    ummm, turbo pascal is still used by many newbie (and long time) developers... not to mention that there are even bbs message base
    formats built on that particular limit... the HMB MSGTXT.BBS file
    is one such... nothing but rows of strings..

    so pascal programmer will have to treat a long-line file as lines
    containing fileds rather than just a bunch of strings,

    as soon as they decide to they can ignore a line they can do READLN; and they'll be at the next line.

    they'll have to use a "readfield" procedure for getting the data from the
    file into strings but that shouldn't be a big hassle, they only need to
    write it once, and can use it for all fields. if done using the ttextrec object (actually not "ttextrec", but that's the naem in the online help) it needn't mean yhe inefficinet practice of repeatedly reading a single
    character searching for a comma.)

    yeah 255 is pretty cramped, way too short for my proposal.

    Probably fewer than 10 rulesets would suffice for 99% of fidonet

    agreed... and my thoughts are that they'd likely be coded in the
    program and this reside in the .EXE (to use dos think for a
    moment)..

    could be, but that makes upgrades hard on the bandwidth unless external rulesets can be used too.

    Bye <=-

    ---
    # Origin: He who Laughs, Lasts. (3:640/531.42)
    * Origin: Baddog BBS (1:218/903)
  • From Jasen Betts@1:218/903 to Goran Eriksson on Fri Jul 26 13:58:08 2002
    Hi Goran.

    24-Jul-02 19:00:48, Goran Eriksson wrote to Haakan Karlsson

    Secondly, how would you convert a zone or region independent
    entry that doesn't announce any POTS capability?

    I don't recognize the problem, maybe I am overlooking something
    in how the nodelist works.

    Converting such a node to a Pvt listing might cause problems.

    FTS-5000 says:

    Pvt --Defines a private node with unlisted number. Private nodes
    are only allowed as members of local networks.

    Even my oldest copy of the FidoNet nodelist specification (FSC-2
    dated 1988-01-02) has an identical requirement. (I would
    appreciate pointers to any other versions of FSC-2, other versions
    of FTS-2 than 1988-11-06 and/or other versions of FTS-5 than
    1989-02-05, 1996-06-01 and 2001-01-03.

    I've not been able to find any explicit, trustworthy and
    contemporary motivation for this requirement, but I'm speculating
    as follows

    The only ones required by administrative FidoNet policy to offer
    inbound netmail routing are the network hosts. (I know that many
    ZC's, RC's and hubs do the same, but that's another thing.)

    Therefore putting a Pvt node outside a local network (e.g. as
    region or zone independents) would mean that there is noone who is required (by policy) to forward netmail to that node

    the ZC is responsible for the contents of the nodelist, if there are unreachable nodes then IMO the ZC (or RC) is responsible for their mail.

    In any case, MakeNl vigorously enforces this restriction

    Yeah, so people put fictional phonen numbers in...
    it's still a private node, it just doesn't look like one to makenl
    (and many other nodelist handling programs).

    and
    therefore I wouldn't be surprised if some other nodelist
    processing tool also rejects such nodes. Furthermore, it would be
    nice to have the 'old style' nodelist so compatible with MakeNl
    that MakeNl can be used to recreate a missing nodediff from two
    'old style' nodelists created by the sort of conversion programs
    that has been discussed here

    sure, a makenl compatible version would be one of the options.

    Bye <=-
    ---
    # Origin: November: The eleventh twelfth of a weariness. (3:640/531.42)
    * Origin: Baddog BBS (1:218/903)
  • From mark lewis@1:3634/12 to Jasen Betts on Fri Aug 16 14:04:16 2002
    i dunno... i'm visualizing the flow in pascal (actually)... i'm
    just seeing the first row filled and then the reading of the next
    line and parsing it for each field just not being that hard... and
    then to overlay the changed fields on the old, no biggie... kinda
    like using a buffer to store the data in and then using different
    structures that are overlaid right on top of that buffer... gosh,
    what is/was the term used for that

    [time passes]

    pkthead1 absolute bheader;

    You can't just "absolute" them over each other because then
    reading one would erase the next...

    i understand that... its the concept... that code snip is from one of my PKT analyzers... it hops between the different ones searching for the one that has the least amount of "garbage" in the fields so as to determine what PKT type (2, 2.0, 2+) is being used...

    understand but also hear others "screaming" about the "bulkiness"
    and duplication of the data... that has always been a bitch...
    "the nodelist is too large. why can't we cut it down in physical
    size?

    size doesn't really worry me... sure whn it was 3 megs it took
    about 20% of my hard space to edit it (for a friend with an
    amiga who didn't have enough ram - neither did I but wordstar
    doesn't need big ram to edit a big file)

    right but it does (still) bother many... this network is dropping folk all the time... the ones who are left are many of our older members... there will come a time when the average age of a fidonet sysop is >50... i suspect that its close to that now if not already more...

    true but it'll still build out to be a line once you get to
    the line terminator..

    depends how you code the reading...

    EOL is EOL is EOL, no matter how you code it...

    255?, that short? why?

    ummm, turbo pascal is still used by many newbie (and long time)
    developers... not to mention that there are even bbs message base
    formats built on that particular limit... the HMB MSGTXT.BBS file
    is one such... nothing but rows of strings..

    so pascal programmer will have to treat a long-line file
    as lines containing fileds rather than just a bunch of
    strings,

    can't! can't read lines/strings longer then 255 characters by default... can only do so with 'outside' code, not stuff already existing in all languages...

    as soon as they decide to they can ignore a line they can do
    READLN; and they'll be at the next line.

    won't work on lines greater then 255 characters... definitely not for a new coder with the free TP 5.5 from borland's site...

    they'll have to use a "readfield" procedure for getting the
    data from the file into strings but that shouldn't be a big
    hassle, they only need to write it once, and can use it for
    all fields. if done using the ttextrec object (actually not
    "ttextrec", but that's the naem in the online help) it
    needn't mean yhe inefficinet practice of repeatedly reading
    a single character searching for a comma.)

    ahhh... i see (now) that you are also thinking in OOP style coding... i haven't
    been... i'm a procedural type of guy...

    yeah 255 is pretty cramped, way too short for my proposal.

    Probably fewer than 10 rulesets would suffice for 99% of fidonet

    agreed... and my thoughts are that they'd likely be coded in the
    program and this reside in the .EXE (to use dos think for a
    moment)..

    could be, but that makes upgrades hard on the bandwidth unless
    external rulesets can be used too.

    what bandwidth? we're talking about a small tool that should be less than 50k... allowing for external rulesets also opens the door for someone to screw something up...

    )\/(ark


    * Origin: (1:3634/12)
  • From Jasen Betts@3:640/531.42 to mark lewis on Sat Aug 17 21:41:04 2002
    You can't just "absolute" them over each other because then
    reading one would erase the next...

    i understand that... its the concept...

    explain the concept then.

    that code snip is from one
    of my PKT analyzers... it hops between the different ones
    searching for the one that has the least amount of "garbage" in
    the fields so as to determine what PKT type (2, 2.0, 2+) is being
    used..

    right, a sort of fuzzy-logic (if you'll excuse the buzz-word) pattern matching


    understand but also hear others "screaming" about the
    "bulkiness" and duplication of the data... that has always been
    a bitch... "the nodelist is too large. why can't we cut it down
    in physical size?

    size doesn't really worry me... sure whn it was 3 megs it took
    about 20% of my hard space to edit it (for a friend with an amiga
    who didn't have enough ram - neither did I but wordstar doesn't
    need big ram to edit a big file)

    right but it does (still) bother many... this network is dropping
    folk all the time... the ones who are left are many of our older members... there will come a time when the average age of a
    fidonet sysop is >50... i suspect that its close to that now if
    not already more..

    there seemz to bemore young people outside of zone 1.

    true but it'll still build out to be a line once you get to the
    line terminator..

    depends how you code the reading...

    EOL is EOL is EOL, no matter how you code it...

    I guess I didn't understand what you meant by "build out to be a line"

    255?, that short? why?

    ummm, turbo pascal is still used by many newbie (and long time)
    developers... not to mention that there are even bbs message
    base formats built on that particular limit... the HMB
    MSGTXT.BBS file is one such... nothing but rows of strings..

    so pascal programmer will have to treat a long-line file as lines
    containing fileds rather than just a bunch of strings,

    can't! can't read lines/strings longer then 255 characters by
    default... can only do so with 'outside' code, not stuff already
    existing in all languages..

    Name one general purpose language that can't handle lines longer than 255 characters witout using external procedures.

    as soon as they decide to they can ignore a line they can do
    READLN; and they'll be at the next line.

    won't work on lines greater then 255 characters... definitely not
    for a new coder with the free TP 5.5 from borland's site..

    New coders?

    program longlines;
    procedure readfield (var f:text;var s:string);
    var c:char;
    b:byte;
    begin
    b:=0;
    if not eoln(f) then
    repeat
    read(f,c);
    if (c <> ',') and (b < 255) then
    begin
    inc(b);
    s[b]:=c;
    end
    until eoln(f) or (c = ',');
    s[0]:=char(b)
    end;

    var
    nl:text;
    master,number,what,where,who,sysflags,ctype,caddr,cflags:string;
    c:integer;
    begin
    assign(nl,'nodelis2.'); reset(nl);

    while not eof(nl) do begin
    readfield(nl,master);
    readfield(nl,number);
    readfield(nl,what);
    readfield(nl,where);
    readfield(nl,who);
    readfield(nl,sysflags);
    writeln (master:6,number:6,what:15,where:20,who:20,sysflags);
    c:=1;
    while not eoln(nl) do begin
    readfield(nl,ctype);
    readfield(nl,caddr);
    readfield(nl,cflags);
    writeln(' (',c,') ',ctype:6,' ',caddr:-30,' ',cflags );
    inc(c);
    end;
    readln(nl);
    end
    end.

    they'll have to use a "readfield" procedure for getting the data
    from the file into strings but that shouldn't be a big hassle,
    they only need to write it once, and can use it for all fields.
    if done using the ttextrec object (actually not "ttextrec", but
    that's the naem in the online help) it needn't mean yhe
    inefficinet practice of repeatedly reading a single character
    searching for a comma.)

    ahhh... i see (now) that you are also thinking in OOP style
    coding... i haven't been... i'm a procedural type of guy..

    The above avample doesn't use any OO stuff, messing with textrec seems to require assembler code (I don't have propper docs or example code so I've stopped looking at that.

    yeah 255 is pretty cramped, way too short for my proposal.

    Probably fewer than 10 rulesets would suffice for 99% of
    fidonet

    agreed... and my thoughts are that they'd likely be coded in the
    program and this reside in the .EXE (to use dos think for a
    moment)..

    could be, but that makes upgrades hard on the bandwidth unless
    external rulesets can be used too.

    what bandwidth? we're talking about a small tool that should be
    less than 50k...

    but has to run on half a dozen different operating systems...
    are you going to distribute binaries for all of them?

    allowing for external rulesets also opens the
    door for someone to screw something up..

    It also allows for someone to fix something.

    Bye <=-

    ---
    * Origin: Misery loves company, but company does not reciprocat (3:640/531.42)
  • From Malcolm Miles@3:633/260 to Johannes Lundberg on Wed Oct 9 16:35:30 2002
    On Jul 20, 2002 Johannes Lundberg wrote to Peter Knapper:

    I thought a bit of this. Using sub-domains for
    services/transport-protocols work quite well? IE, to find out if
    host 2:206/149 has binkp-access, you simply resolve 'binkp.f149.n206.z2.fidonet.net'. And to list the services
    available, you do a zone transfer on f149.n206.z2.fidonet.net. Port specification could be solved with a record looking like 'p4001.binkp.f149...'. The old BinkD @fidonet.net way would still
    work, as the f149-record would point to the right IP already. And
    new software developers would be instructed in using the new format.

    (This could also be done using a IN HINFO-record in the DNS, to
    avoid zone transfers)

    Better to use the SRV record as this directly returns a host and a port eg:

    dig srv _binkp._tcp.f260.n633.z3.fidonet.org

    ; <<>> DiG 8.3 <<>> srv _binkp._tcp.f260.n633.z3.fidonet.org
    ;; res options: init recurs defnam dnsrch
    ;; got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4
    ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2,
    ADDITIONAL: 1
    ;; QUERY SECTION:
    ;; _binkp._tcp.f260.n633.z3.fidonet.org, type = SRV, class = IN

    ;; ANSWER SECTION:
    _binkp._tcp.f260.n633.z3.fidonet.org. 1D IN SRV 0 0 24554 fido.tardis.net.

    shows that to make a binkp connection to 3:633/260 connect to fido.tardis.net on port 24554.

    Best wishes,
    Malcolm

    --- timEd/386 1.10.y2k+
    * Origin: Tardis BBS +61 3 9819 7093 (3:633/260)
  • From Malcolm Miles@3:633/260 to Johannes Lundberg on Wed Oct 9 16:42:33 2002
    On Jul 21, 2002 Johannes Lundberg wrote to Peter Knapper:

    Relying on one single server is not very good. Especially not if ALL mail-transfers depends on it. That's one potential problem using
    such a system (as the DNS-system, or a system of our own). If the "root"-server (the DNS-server for the domain, like fidonet.net) goes
    down, not a single conversion from 4D-adress to IP and Services can
    be done during the downtime.

    That is why you always have multiple domain servers set up. For example z3.fidonet.net is hosted on 2 DNS serers, verdi.tardis.net here in Australia and ns.fidonet.net in Russia. No reason why you could not add others.

    Best wishes,
    Malcolm

    --- timEd/386 1.10.y2k+
    * Origin: Tardis BBS +61 3 9819 7093 (3:633/260)
  • From Goran Eriksson@2:201/505.1 to Haakan Karlsson on Fri Sep 12 22:02:40 2003
    A comma separated list is not very flexible, but instead inherently
    quite rigid. A flexible format have to be built on field
    identifiers, that is the only way to guarantee future extentions
    without breaking existent next generation software.

    I believe that a comma separated list can be reasonably flexible provided that all software that process it is written with extensibility in mind.


    Among other things this means that processing software should from the very start be written to tolerate unknown fields.

    Field identifiers (or rather field group identifiers) could be used to identify
    each group of connectivity related fields:

    ,505,GET,Lulea,Goran_Eriksson,\
    *POTS*,46-920-257910,33600,XX,V34,\
    *ISDN*,46-920-257910,64000,CM,XX,X75,\
    *IBN*,getibn.nospam.se,CM,\
    *ITN*,getitn.nospam.com:9999,CM,\
    *ISE*,irex@get.nospam.com

    where the \ only implies line-breaks which have been inserted here for clarity.

    With this

    1. I can specify different on-line hours for different connectivity types all in one nodelist entry.
    2. I can specify different host names and different ports for IP protocols all in one nodelist entry.
    3. I can specify different file request capabilities for different connectivity
    types all in one nodelist entry.

    and a number of other things I haven't demonstrated above.

    New connectivity field groups may be added (e.g. *AX25* for packet radio links)
    without any problems provided that older software understands to gently ignore the AX.25 connectivity group. The internal syntax of a connectivity field group
    can be freely defined as long as no ambiguities arise.


    One advantage with a text file format is that it's easy to maintain the information in the nodelist with your favourite text editor.

    ---
    * Origin: GET, Lulea, Sweden, +46-920-257910 (2:201/505.1)