On Jan 12, 2006, at 7:16 PM, Florent Guillaume wrote:
Gary Poster wrote:
We frequently want to know the full closure of group membership.
+1, a long time ago I suggested something similar because in the
CPS framework of groups we need knowledge both of direct membership
and transitive closure (we have a getGroups method that's the
direct groups, and a getComputedGroups that's the transitive
closure and is used for instance when we have groups of groups).
I'm still not using the zope 3 principal framework but at some
point I know I'll need it in zope 3 too :)
Do you think your interfaces fit the need of "computed" groups? I'm
not sure if the meaning of "computed" is clear but I can expand on
that if it's not (for instance, it could be for the case where
groups exist dynamically according to some computation on the
I know what you mean--we've done that in Zope 2 also.
I think my change fits the need of computed groups fine: computed
groups would be a part of the direct iterable of `groups` for a
principal, from which the full closure (`allGroups`) would continue
to be calculated.
The current IPrincipal interface has a bit of a problem for computed
groups but is pretty close, I'd say. Right now, the core principal
interface in zope.security says that `groups` is a list. A list that
has an unremovable member--a calculated group--is a bit hacky to
model, so you might want to have a different API for mutating the
groups--or maybe it's *all* calculated and imutable. If this core
interface were restricted to say that `groups` is a readonly iterable
(which would be sufficient for the security policies I know, AFAIK),
and then another interface extended it to match the current interface
(a list), then the core interface would allow other principal
implementations to determine the `groups` value in other ways.
That change sounds good to me, but also sounds like a separate mini-
Zope3-dev mailing list