On Apr 28, 2013, at 9:58 PM, Stephen J. Turnbull <step...@xemacs.org> wrote:
> Richard Wackerbarth writes: > >> 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. > > But here the limits apply to *principals*[1], not lists, AFAICS. That is the case in my hypothetical example. However, the mechanism applies to any property of the lists such as a default value for some user preference. In my example, the property is, perhaps, "Administrator can/cannot create a new list" Equally, the content of a "Greeting Message" or the "Default Language", or any other property can be treated in the same manner. > I could see this organization being usable in a case where ... > It's not obvious to me that your way of doing things is better for > this use-case. If it's not plausible that it's better (I make no > claim that it's not at this point), it fails to justify an experiment > with a generic organization for lists. You seem to be missing the point that "one size fits all", or in this case, one hierarchy, is not a flexible strategy. By having a generic structure and allowing each installation to customize the hierarchy to fix their individual need, we provide a mechanism that better suits the needs of a larger group of installations. >> 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. > > This is more plausible as a use-case, since the "certain nodes" need > not be all the nodes for that administrator. OTOH, we already have > "list owner" and "moderator" roles, and those *are* attached to each > list. It's not clear to me that we need to provide for adding > additional roles, but I'll keep it in mind. I'm advocating that we attach the roles (whatever they may be) to an entire collection of lists. The purpose of a hierarchical structure, whether one fixed structure or a generic recursive one, is to provide a mechanism to assist the "principal" in managing a number of lists that have common properties. 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. _______________________________________________ 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
