Subj : proposed new nodelist
To   : mark lewis
From : Jasen Betts
Date : Wed Jul 24 2002 02:07 pm

Hi mark.

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

FV>> Yup. As long as there are no fields that are used by one
FV>> node, but not by others. Such fields should be grouped
FV>> and not given an individual section. Otherwise, the
FV>> structure of any list falls apart.

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

ml> as long as a POTS node remains in fidonet, there will be field that
ml> 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

ml> as for the grouping, remember, this is a technical network... it is
ml> very easy for me, as a programmers, to write a program that reads a
ml> line of test and seperates it into 8 fields with the last field
ml> 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)