>From: Thomas Habernoll <HABERNOL@DB0TUI11> >I think it should be possible for a user to perform all mailing list >related things at his/her local node, especially as I expect the >number of users not familiar with details of e-mail to grow rapidly >in the future. And I really have a better use for my time then >to explain them why to send this command to Listserv at Anywhere >and that letter to Foobar-Request at Arpaland. This is why I've >tried to add DB0TUI11 to some peered lists. >From: Andrew Vaught <29284843@WSUVM1> >In-Reply-To: Message of Wed, > 6 Apr 88 13:35:12 EDT from <[log in to unmask]> >>I tried to issue the UNSUBSCRIBE REXXLIST command to the list >>server, but it claimed I am not subscribed to the list. Yet I >>am receiving volumes of mail from the list, so I clearly am >>subscribed to it. Please remove >> [log in to unmask] >>from the REXXLIST mailing list. Thank you. >> - reg >>Rick Genter ...!buita!lti!reg >>Language Technology, Inc. [log in to unmask] >>27 Congress St., Salem, MA 01970 > > I've had this problem before. Apparently a list is controlled by one >LISTSERV with satellite LISTSERVs handling distribution across the net. >If you ask to subscribe to a list, a satellite will forward the request >to the master server. You can't do this with UNSUBSCRIBE for some reason. >You have to UNSUBSCRIBE from the master listserv, ... I was always wondering, why the services offered by all those LISTSERV machines are not transparent, i.e. why you always have to keep in mind which LISTSERVer serves which list. With a really user friendly service you should always have to just talk to "your" LISTSERV, and this machine would then either process your request itself or forward it to the nearest LISTSERV which is capable of processing it. For this to be possible, some things would be needed: 1. Every LISTSERV has to maintain a table where all nodes of the net are paired with "their" LISTSERVer. This will enable it to pass requests erroneously sent to it to the correct LISTSERV. 2. Every LISTSERV needs a table where ALL mailing lists (netwide) are paired with the name of the "nearest" peer (where "nearest" is meant here with respect to some apropriate cost function). 3. Both tables would have to be kept consistent among all LISTSERVs and up to date by some update protocol. 4. For every mailing list, each LISTSERV maintains a list of "regional" recipients, i.e. recipients sitting at one of the nodes for which that LISTSERV is responsible. It is the LISTSERV that is primarily subscribed to the various lists. It then redistributes mail to the "regional" subscribers. Therefore subscribing will be a "regional" matter regardless of where the next peer resides. This concept looks a bit as if every LISTSERV peers every list, but this is only true with respect to distribution of mail, not with respect to keeping notebooks or other database information. This will still be the job of the real peers, the only difference being, that any request is sent to the "regional" LISTSERV first. Other services (AFD, FUI, FILELISTs etc) could follow a similar pattern. Is this just a nice dream or could LISTSERV be slowly migrated to such a setup? Or am I the only one who thinks this worth considering at all? Any comments apreciated. Rainer .----------------------------------------------------------------------. | Rainer M. Woitok | Phone : (+49 9131) 85-7811,-7031 | | Regionales Rechenzentrum | Bitnet : [log in to unmask] | | Friedrich-Alexander-Universitaet | | | D-8520 Erlangen | | | West Germany | | '----------------------------------------------------------------------'