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...
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..
Bye <=-
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..
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;
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?
true but it'll still build out to be a line once you get to the
line terminator..
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..
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)..
Bye <=-
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
Bye <=----
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
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.
Bye <=-
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.
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
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
Bye <=-
Ok. Hang in there with me. I'll try to make this short (yeah,
right :-)
New Nodelist format (all on one line):
1. The Node number. Well, duh, that's the prime thing, isn't it?
2. The system name. This is an "address book, after all. :)
3: The location of the system. Well, to generate an "old style" list,
this is needed and is nice to know anyway.
4. The name of the operator of the system. Good to have since we are dealing with human beings here. :-)
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.
8. FV> The phone number if POTS capable. If not, -Unpublished-.
9. Modem speed. 300 if IP node?
up for the "old style" list.
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.
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.
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.
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.
Ability to generate an old style list is required... at least until
there are no more mailers requiring that style of list.
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.
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.
This will require new programs to
make things work and conversion programs for backward
compatibility.
http://pages.sbcglobal.net/flv http://biseonline.com/r19
Bye <=-
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>
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..
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?
heck, we could code some sort of comma-encoding to
show number of empty comma fields is that is a problem..
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)..
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..
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 :)
via snailmailed tapebackups..
)\/(ark
Bye <=-
Hmm, does anyone know what's an "RVIA" flag for and where is
it documented?
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...
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...
yeah... gruping flags together like that makes sense
Thank you.
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.
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.
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 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. :-)
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.
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)
Bye <=-
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.
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...
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.
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).
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...'.
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.
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.
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.
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.
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
Bye <=-
^^^^^^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)...
not sure of the reference... i was thinking of keeping the POTS
data the same and building from there..
why keep pots?
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.
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.
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"
:-))
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.
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.
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)
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.
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 "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...
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)
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.
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...
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)...
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..
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?
then you loose the placeholders... they are needed if they are the
first row for that entry, too..
that's actually a normal part of fido mailer communications...
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..
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..
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..
Bye <=----
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...
Bye <=----
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
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>
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"..
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>,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?
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..
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..
still have some problems with this format, i'm positive...
however, i cannot think of anything other than linelength parsing
at the moment..
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..
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>>
Bye <=----
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.
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.
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? :)
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 :)
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.
Pvt --
Defines a private node with unlisted number. Private nodes
are only allowed as members of local networks.
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...
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..
Bye <=-
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..
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;
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?
true but it'll still build out to be a line once you get to the
line terminator..
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..
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)..
Bye <=-
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
Bye <=----
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.
You can't just "absolute" them over each other because then
reading one would erase the next...
i understand that... its the concept...
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...
door for someone to screw something up..
Bye <=-
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)
dig srv _binkp._tcp.f260.n633.z3.fidonet.org
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.
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.
| Sysop: | digital man |
|---|---|
| Location: | Riverside County, California |
| Users: | 1,067 |
| Nodes: | 17 (0 / 17) |
| Uptime: | 13:55:48 |
| Calls: | 501,254 |
| Calls today: | 1 |
| Files: | 109,407 |
| D/L today: |
1,968 files (6,294M bytes) |
| Messages: | 302,049 |
| Posted today: | 1 |