Hi mark.

10-Jul-02 14:26:42, mark lewis wrote to Haakan Karlsson


 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 easily
 HK>> solved by a convertion program that outputs an old style nodelist
 HK>> that can serve as input to the old software.

 ml> agreed, but what limitations are you seeing that i haven't covered
 ml> 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 the
 HK>> new format in paralell. That will give all nodes time to upgrade
 HK>> their nodelist compilers or install a convertion utility. Then
 HK>> the old format can be smoothly phased out.

 ml> 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
 PK>>> not at all very flexible in this case), and be able to work in
 PK>>> ways the Nodelist was never designed t work. I think this new
 PK>>> format already 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 not
 HK>> want a DNS for it.

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

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

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

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

information part of the style ?

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.

 ml> why have to add field identifiers
 ml> and then have to create "smart" programs that have to be able to
 ml> 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)

 ml> it is
 ml> much faster to read data directly from where you know it is to be
 ml> rather than having to hunt it down... not only faster, but easier
 ml> 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.

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.

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

 -=> Bye <=-

---