PK>> ..we should not tinker with the current Nodelist format at all..
 PK>> ..If data REALLY needs to be added to the Nodelist, then it MUST
 PK>> be done in a totaly transparent way..

 HK> That imposes far too many limitations, I see no other options
 HK> than a major change. As long as all the needed information is
 HK> included in the new format, the compatibility issue can be
 HK> easily solved by a convertion program that outputs an old
 HK> style nodelist that can serve as input to the old software.

agreed, but what limitations are you seeing that i haven't covered with my tidbit?

 HK> There is nothing that stops defining a new file-echo for a new
 HK> nodelist format and for a period distribute both the old and
 HK> the new format in paralell. That will give all nodes time to
 HK> upgrade their nodelist compilers or install a convertion
 HK> utility. Then the old format can be smoothly phased out.

exactly...

 PK>> IMHO, Fidonet should be developing a NEW data record format that
 PK>> completely replaces the Nodelist, but still keeps Fidonet nodes
 PK>> connected. It MUST be flexible (the current Nodelist format is not at
 PK>> all very flexible in this case), and be able to work in ways the
 PK>> Nodelist was never designed t work. I think this new format already
 PK>> exists today, its called DNS.

 HK> I don't follow You there, perhaps You can explain with an
 HK> example? The DNS system only resolves IP numbers, it does not
 HK> indicate what services are available and on what ports they
 HK> reside. There are also nodes having a static IP that perhaps
 HK> not want a DNS for it.

thank you! those are some of what i was thinking of...

 HK> A comma separated list is not very flexible, but instead
 HK> inherently quite rigid. A flexible format have to be built on
 HK> field identifiers, that is the only way to guarantee future
 HK> 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... i don't believe that we should add any more
info to the current database style other than what is absolutely
necessary... 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? 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...

)\/(ark