> I can think of several options:
>
> (1) Take them from the first sublist that the subscriber appears on.
>
> (2) Take them from the last sublist that the subscriber appears on.
>
> (3) Ignore the subscriber options but apply the Default-options from
> the superlist.
LISTSERV takes the options from one of the sub-lists that the subscriber
appears on and that qualifies the subscriber for receiving the message.
That is, LISTSERV first ignores subscriptions which would not lead to
the message being delivered to the recipient (for instance because the
topics do not match). From the remaining sub-lists, it picks one as close
as possible to the super-list (ie a first-level sub-list pre-empts a second-level
one). NOMAIL subscriptions disqualify the sub-tree under the NOMAIL
list for purposes of supplying subscriber options (and selecting the
subscriber as a recipient), but are pre-empted by non-NOMAIL
subscriptions at the same level.
Given that any list can potentially be the sub-list of any other list(s), there is
no easy and intuitive way for a user who does not know anything about
the details of the sub-list structures implemented by the list owner to
understand where the options come from. The users will typically know
which sub-list(s) they are on, but may not even have known that the
super-list existed until they received their first message and wondered
what this list is and why they have been subscribed to it! The most
popular super-list setup has a depth of one (ie you have one or more
super-lists which each point to a number of sub-lists that are normal
lists with no further sub-lists), in which case the user cannot predict
which sub-list the options were taken from, as it depends on the order
in which the list owner happened to list them in the super-list. Besides,
the sub-lists in question are generally similar (dept. of X, dept. of Y
and so on) and there is usually no logical choice for a "better" list
to get the options from. Finally, if you leave list X, your options will
be taken from list Y and your subscription to the super-list will
effectively change, even though you still receive the messages.
The only way for the process to be intuitive to users who may have a
hard time understanding the concept of recursion is for them to be
subscribed to the super-list. In this case, the options are always
taken from the super-list (there is no other list at the same depth)
and things are simple and straightforward. Another way of course
would be for each user to be subscribed to only one sub-list, but
usually the reason super-lists are used is that this is not the case
and duplicates are undesirable.
> The current situation, in which there is no control over subscriber
> options, seems the least ddesirable.
The REPRO option does not work because the fate of the REPRO
copy is decided before the sub-lists are scanned. The procedure
that reads the lists and decides who gets the message is provided
with a list of addresses that should be skipped, and this will include
the sender's addresses unless REPRO was previously detected.
REPRO does have a strange implementation, but this is not really
the problem. Options like NOPOST or REVIEW also operate long
before the mailing is prepared and the list of recipients is extracted,
which makes a lot of sense since this is a resource-intensive
operation and it would be silly to abort it when you suddenly realise
that the sender has NOPOST after all. The current super-list
implementation cannot consistently apply recursive options to
the sender. This may be solved in a future version by doing two
passes on the super-list structure, but currently only the top-level
list is searched for a subscription entry.
Eric
|
