[Mailman-Developers] Architecture for extra profile info

[Stephen J. Turnbull]

Richard Wackerbarth writes:

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

You don't need to teach Grandma how to suck intensional
vs. extensional Python eggs.

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

Ie, the advantage of being generic is that it's generic.

 > Note that "core" doesn't NEED the structure to function.

Of course not, the only structure we NEED is a tape that's lightyears
long, and a finite automaton that Turing designed in the 40s IIRC.
Sorry for the sarcasm (well, a little bit sorry), but in deciding on
design principles we need to evaluate simplicity, practicality, etc
from the point of view of the people involved.

The question is whether structure makes the program easier for users
to use and for developers to create and maintain.  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 makes it easier to
think about requirements and write code to satisfy them.

 > 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"?

 > as the list/list-group identifier, we get the generic hierarchy as
 > a byproduct.

No, that's not enough.  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.

 > 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.  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.
 > 
 > 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.  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 don't see a simplification for the reasons expressed above.

What are the use cases for a more generic structure?