[Mailman-Developers] Architecture for extra profile info

[Stephen J. Turnbull]

Richard Wackerbarth writes:

 > You seem to be missing the point that "one size fits all", or in
 > this case, one hierarchy, is not a flexible strategy.

Sorry, that's false, and there's plenty of evidence in the archives
that I've acknowledged that point.

But "flexible" is not an absolute, not even if you're discussing
female gymnasts.  My point is that IMHO it's flexible *enough*.

 > I'm advocating that we attach the roles (whatever they may be) to
 > an entire collection of lists.

I know what you're advocating, and I agree with the general theory of
constructing for flexibility.  I just don't see a need for it.

 > Actually, by establishing a flexible hierarchy, it may be possible
 > to eliminate some of the functionally similar roles. For example, a
 > "Domain Administrator" might be nothing more than a "List
 > Administrator" attached to a higher node in the tree of Lists.

Sure.  That's the main point of a generic model, sharing code to
handle cases that are similar enough to handle with the same code.

However, I don't think it's true that they're that similar.  By the
principle of subsidiarity, there are things that a List Administrator
does that a Domain Administrator normally shouldn't do (authorizing
moderators).  But there are others that both should be able to do
(clearing queues of broken messages, removing legally objectionable
messages from archives).

So to handle both attributes that are subject to subsidiarity and
those that aren't, you need as much code as in the current model,
*plus* in your model you need to make the code generic *and* provide
rules for the existing use cases.  That just doesn't sound like a
bargain to me in the absence of a few plausible *and concrete* use
cases that require more flexibility.

Steve