This is a proposal for a new DISTRIBUTE backbone. For technical reasons which I will explain in another note, I will have to redesign the DISTRIBUTE algorithm to avoid loops and to avoid the frustrating "No recipient for this server, probable loop symptom, I've sent all the stuff direct (as SENDFILE would have done) because my mumma was not here to tell me what to do and I didn't want to do no bad thing". I will also have to implement full RFC822 support into it. This new DISTRIBUTE will NOT be compatible with the previous one, so it must be implemented as a new test command (eg DIST2), working on a more restricted backbone (eg release > 1.5i). When the command has been tested and its backbone is large enough, it will be possible to phase the old DISTRIBUTE out and rename DIST2 to DISTRIBUTE. The syntax of DIST2 will be compatible with that of DISTRIBUTE from the user's point, but the server-to-server protocol will be different and incompatible with the old one. That is, the user will not notice any change when DISTRIBUTE is phased out to DIST2, except a few additional options and slightly different messages. I therefore propose to define two categories of servers in the future: 1) Local server. A local server has no obligation towards the network. It can run any release of the code, update when its postmaster sees fit, be placed offline from 1am to 11pm, etc. The server will appear in PEERS NAMES but it will be flagged as being a local server. The only two restrictions are: - If the postmaster complains about a problem with LISTSERV and he is not currently at the latest level, he will receive a note telling him that his problem will not be addressed until he has upgraded to the latest available version. This is stupid and irritating for the postmaster but I am afraid I have no other choice. - Local servers are not allowed to create peer lists. Note that the term 'peer list' should be interpreted as meaning 'network-wide public peer list'. A closed peer list local to the various nodes of an institution does not fall into that category. A local server can create a network-wide list by means of the Mail-Via= DISTRIBUTE feature. Local servers can submit DISTRIBUTE jobs to the backbone, but will not receive any. If a peer sub-backbone is required for the list (eg if large archive files are to be made available), the local server's postmaster should try to find hosts in the backbone or should become a member of the backbone. The code will let the local server create peers but this will be strictly under the postmaster's responsibility and I will provide no support if a problem arises, files are lost, etc. Again, this is stupid but I have no other choice. 2) Backbone server. A backbone server can do all of the above, can create peer lists and is supposed to receive DISTRIBUTE jobs. The restrictions are the following: - A backbone server should always be at the latest available level. This means that the postmaster should either allow me to update the server remotely, or take whatever steps are necessary to update it in a timely fashion. This means the average delay should not exceed 1 week, and the deadline should be 2 weeks. More than 60% of postmasters install the code within 3-4 days so this should not be a problem. - A backbone server cannot be placed offline on a regular basis. It must operate 24 hours. It can of course be placed offline manually under particular conditions, lists can be held by their owners, etc. - A backbone server must be AUTOLOGged when the system IPLs, and ought to be automatically restarted every N hours if it ever logs off (if such a restart facility is available at the host node). Operators should be able to restart it if they are also able to restart RSCS, etc. That is, the institution should do its best to have the server restarted after some delay if it gets a paging error from CP, or suchlike. - A backbone server should have the latest version of BITEARN NODES, or at worst last month's version. Not the 8609 version. I am aware of the delays in the distribution of BITEARN NODES and I know that it can take one month to install it, but certainly not 5 months, especially if the guy down your path to BITNIC has the latest version :-) - To facilitate the maintainance of peers lists, a PEERS FILELIST will be created (maintained by the LISTSERV coordinators) on all the servers of the backbone. For each 'known' peer list, four files will be added to the filelist and maintained by the owners of the list. These will be: o 'listname PEERS' -- just the "Peers=" keyword and the linkage topology for the list. Maybe also the "PW=" keyword. o 'listname DESCRIPT' -- a descriptive blurb about the list. o 'listname HEADER' -- all the other global keywords. o 'listname LOCAL' -- keywords that are local to each server. This file will usually be empty and will be maintained by the local postmaster, NOT by the list owner. It is supposed to contain keywords like "Notebook=" which differ from server to server. All these files will be linked to the list using .IT and .IK statements, as appropriate. Servers which don't have the corresponding list will reject the PUT command without sending any reply back to the owner. That is, no space will be wasted on their disk, except for the entries in the filelist. This will be done automatically by means of an access control exit. Alternatively the postmaster may opt for receiving the file anyway so that his server has a list of all peer lists with their descriptions. It would then be easy to create a file like LISTSERV GROUPS automatically, from this information. We would need a few such servers here and there (every 4-5 links or so). It would then be possible for someone to volunteer writing local commands which would allow people to access this "lists database" interactively, eg "I am interested in a PROLOG discussion list, is there something like that?" -- just search the list descriptions for PROLOG and you have it. This system implies that the PUT command will be sent to "useless" servers but this is not very important as these files will be very small (at worst 20 lines), and not updated every day. But it will be infinitely easier to maintain. Local mods: If I were an AI program written in PROLOG, I would strongly encourage all sites to make as many local mods to their operating systems and LISTSERV as possible, as those sites which have local mods are those which cause me the smallest amount of problems. Paradoxically, they always install updates in time and almost never contact me about problems with the code, even though they DO have a bunch of problems usually. Of course I am not a PROLOG (*yuk*) program and I won't give you that kind of advice, but I have no objection about sites with local mods participating to the backbone. As long as it works normally when seen from outside, it's ok with me. So, would this be ok with you? Eric