[Mailman-Developers] Architecture for extra profile info

[Richard Wackerbarth]

On Apr 29, 2013, at 8:12 AM, Stephen J. Turnbull <stephen at xemacs.org> wrote:

> Richard Wackerbarth writes:
> 
>> So you have at least three layers. Do you really think that it is
>> more difficult to implement a general recursive tree than it is to
>> implement those layers?
> 
> No.  What I think is difficult is to implement a general recursive tree
> *and* an API for expressing properties of nodes that make them
> equivalent to the specialized hierarchy *and* a usable interface for
> specifying and managing those properties by non-programmer users
> (including admins).

There are two aspects of using a "generic tree". The first is some customization of the tree to fit the installation's delegation model. Here, I would suggest that "sample base installations" be made available so that the installation of a workable tree structure is nothing more than copying a supplied configuration base. "Power users" should be able to understand the structure and customize it to fit their particular situation.

The other aspect is "how to display" them, particularly because of inheritance within the tree.
I don't see "display the tree of lists" as a problem. There are a number of reasonable implementations available for adoption.
IMHO, the key to displaying particular the individual parameters is to use a consistent presentation style and "focusing" on a particular node in the tree.

That style can be driven by css using class selectors on each individual item.

As for "domain" vs "list", I view them as just two versions of the same thing -- namely a node with a dictionary of properties.

By limiting access permission, even though they are present (in a virtual sense), and by modeling each list as having all of the properties of itself and the MM-domain which contains it, we can use one mechanism to handle the both the domain administrator and the list administrator. The only distinction is the point of focus.

>> Another case for generality is permissions. I don't propose to know
>> all of the parameters that will be associated with a list.
> 
> You're pushing on a string here.  I'm not opposed to generality in
> general. ;-)  What's more important to me than whether you know all of
> the parameters that will be associated with a list :-) is that I'm
> pretty sure I don't want Postorius's views to know.

Postorius need only know about those items that should be viewed or modified once the system is running.

>  That leads to ugly and unmaintainable code.

Or you can treat them in a generic manner, even make them "discoverable", and attach the appropriate ACL information.  :)
This is, in effect, the approach that django takes with its "Model" and "Admin" constructs.

One reason that I advocate attaching the parameters to the list-tree nodes as a dictionary is so that it is easy to add or delete items without having to change the data transfer structure.

> I also don't want users to be seeing data they don't need to see, or
> shouldn't see, and they mustn't be able to change parameters they
> shouldn't change.

Agreed. One purpose of a list hierarchy is to make it easier to specify and maintain these attributes.

>  These requirements can be fulfilled in a number of
> ways, including customization by extension modules.  For example,
> there could be (extensible) lists of parameters attached to each role,
> a list for each permission.
> 
> I think that's kind of fragile; better to attach an ACL to each
> permission.  (I think that's basically what you have in mind, too.)