[Mailman-Developers] Architecture for extra profile info

[Richard Wackerbarth]

On Apr 27, 2013, at 9:15 AM, Stephen J. Turnbull <stephen at xemacs.org> wrote:

> Richard Wackerbarth writes:
> 
>> It is not necessary to have more than a flat collection of lists.
> 
> I don't know how it will be represented, but we *do* need to support
> virtual hosting, where the mailman administrator delegates site
> administration to the owner of the virtual host.

A list is a first class object. Each list has its own set of parameters which characterize it.
One portion of those characteristics is the administrative permissions associated with the creation and alteration of the list.

Groupings of lists simply provides a "shorthand" for the description of characteristics which are common to the group.

>> In fact, that approach has the advantage that each list can be
>> allowed to have individual configuration parameters. At the
>> present, he has attached the "base web URL" to the
>> email_domain. Instead, I would like to have the ability to set that
>> on a per-list basis.
> 
> I think that's reasonable.
> 
>> Rather than defining a specific structure, I would substitute a
>> more generic structure defining collections of lists. This tree
>> could be configured to represent any organizational hierarchy that
>> the installation desires.
> 
> Such flexibility has benefits and costs.  How many of our users will
> need/want this flexibility?  (Genuine question.  I personally don't
> want it, so it's hard for me to estimate.)

The advantage in using the generic structure is that it does not impose any pre-supposed structure on the collection of lists.
Note that "core" doesn't NEED the structure to function. The structure can be imposed by having the interface agent impose constraints on the members of a group of lists and mapping an operation on the group into that operation on each of its members.

If we use a MPTT key as the list/list-group identifier, we get the generic hierarchy as a byproduct.

The only real issue is how we would express constraints that get delegated.

But we need to address that issue for any structure that we establish.

Virtual hosting is the primary example of the need for a hierarchical administrative structure. However, it can also be useful in corporate structures where the email address space might be partitioned in a quite different manner.

From a design perspective, the "core" message handler should be distinct from the configuration administrator.
Message handling uses the current value of various configuration parameters. It need not, and should not be concerned with the mechanics related to the setting or modification of those parameters.

Since these parameters seldom change, an effective caching mechanism would address access performance issues.