[Mailman-Developers] Architecture for extra profile info

[Richard Wackerbarth]

On Apr 28, 2013, at 11:15 AM, Stephen J. Turnbull <turnbull at sk.tsukuba.ac.jp> wrote:

> Richard Wackerbarth writes:
>> Note that "core" doesn't NEED the structure (of list heiarchy) to function.
> in deciding on design principles we need to evaluate simplicity, practicality, etc
> from the point of view of the people involved.
Agreed.

> I think the tried and true hierarchy (site -> virtual hosts -> lists) matches some a
> natural hierarchy in administrative responsibility and user understanding of this corner of the Web.
That matches ONE organizational hierarchy. There is no reason that you cannot use a more general structure and still follow that organizational structure.

>  That makes it easier to think about requirements and write code to satisfy them.
Not necessarily.


>> 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.
> 
> Yes, and we'll have to create a language to express those constraints
> and an interpreter to enforce them, *and* create objects like "site"
> == Mailman instance and "vhost" out of the abstract groups.  Costs,
> benefits, which is bigger?
> 
>> If we use a MPTT key
> 
> "Ministry of Posts, Telegraph, and Telephone"?  "mildly paranoic teletype"?

Modified Preorder Tree Traversal

> Sites and virtual hosts have attributes besides lists (websites, the "mailman" list, owner and admin
> addresses, ...).  There should be objects that correspond to those concepts to carry those attributes.

I think that I view it differently.  EVERY list has, for example, an "admin address". If there is only one list, to the user(administrator) that attribute belongs to the (only) list.  It is only when you have a collection of lists that share a common value that a hierarchy adds value. In that case, by defining a default value to the node representing the collection and specifying "inherit from parent" in all of the sub-nodes, you can, administratively simplify the maintenance of the value to be used in each instance.

>> 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.
> 
> True, but it's not a question of need to or not, it's a question of
> costs and benefits.  Generic code is more expensive to create and
> maintain in many cases.  I suspect it will be here, as well.

Yes, initially generating a more generic structure than the ad hoc one in place (which doesn't even attempt to address delegation) is a bit more expensive for the first few parameters. However, in the log run I suspect that it won't be more expensive. Creating a single, reusable mechanism for the specification of delegation of authority will actually produce an easier-to-maintain scheme. And, ad hoc approaches are notorious for becoming unmaintainable.

>  Without use cases for the generality, it's hard to see the benefits.  When do you expect the generality to be of use?
> 
>> 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.

There is no need to make a distinction between the levels in your list hierarchy tree.
Treating each level as a specific case of a generic structure allows reuse of a common code base.

>> 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.
> 
> I have no clue what you're trying to express here.

This is addressing the modularity of the system, separating functionality and utilizing particular views of the stored data rather than dictating how the data is stored and manipulated.

>  I don't see any performance issues, except that programmers whose brains have exploded
> from cognitive overload tend not to produce double-digit KLOC/hour.
> My concern is entirely whether the design you propose simplifies the
> job of meeting the common requirement of creating a (1 to 3 level)
> hierarchical organization of lists (the third level being the children
> of umbrella lists), or serves important use cases without
> significantly complexifying the job of serving the common case.

I argue that it simplifies the case that you mention because it provides a uniform way to deal with all of the aspects, especially the delegation aspects which are not addressed in the present scheme.

> I don't see a simplification for the reasons expressed above.
> 
> What are the use cases for a more generic structure?