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
|
