I am thinking of "delegation" in the context of administering list properties and preferences.
Assume a hierarchy of lists handled by one (or more) servers that comprise a MM system. Various "persons" could be assigned authority to make changes that affect lists within portions of the tree. those changes might in things such as setting the default language or the ability to create a new list. In the virtual hosting scenario, provides a number of possible opportunities to illustrate how this might be used. The "root" of the tree covers all of the lists. Under that top node, we might create nodes for "Customer Plans", for example, "Bronze", "Silver", "Gold" and "Platinum". Each of these nodes would specify some limits that applies to the level of service. Let us assume that the Bronze service plan allows the customer to have only lists set up by the Provider staff. That user might still be allowed to set other parameters, for example, the subscription policy and the"welcome message". Under the Silver Plan, a customer might be allowed to set up new lists within their own email-domain. In both of these cases, a subordinate node would be created under the appropriate "plan" node for the list(s) of that customer. And under those nodes, we would find various individual lists. Now, within our permissions system, we would grant the customer administrator permissions to alter certain parts of the list parameters. In my example case, the right to create new lists would not be granted to the customers in the Bronze plan, but would be granted to those in the Silver plan. Another right is the ability to permit the administrator to associate additional persons to nodes within their portion of the tree. By doing so, that administrator "delegates" the ability to perform certain operations to this added person. Note: I am not trying to present the complete set of details, only trying to indicate how such a framework might be utilized. The reason that a generic mechanism has value is that the same type of "permissions" logic is utilized for any parameter describing the list behavior. Whether you are selecting the default user preference to "receive digest" or specifying the email address or website URL through which someone can "unsubscribe", except for the filtering on permissible data values, the mechanisms needed to handle an input form are very similar. Richard On Apr 28, 2013, at 6:54 PM, Stephen J. Turnbull <step...@xemacs.org> wrote: > Richard Wackerbarth writes: > >> Yes, initially generating a more generic structure than the ad hoc >> one in place (which doesn't even attempt to address delegation) > > Aha! Something that looks like a concrete use case! But what is > "delegation"? I mean, "who delegates what to whom? And why does > Mailman need to address it? What code needs to be written to address > it? > > The rest of your post is just a reiteration of your religious belief > that generic is good. > > I know the theory, but without use cases I will devote my efforts > elsewhere, and ignore complaints that my code or my advisee's code is > insufficiently general or that it ignores a theoretical design that > has no code or use case to back it up. _______________________________________________ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
