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