>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                     |                                   |
'----------------------------------------------------------------------'