On Oct 8, 2005, at 11:49 AM, mario ruggier wrote:

> I had this idea an mind:
>
> class Permissions(PersistentDict):
>
>     data_is = { (string,either(Persistent, True)) : either
> (permission_info_obj, True) }
>
>     ...
>
>     def is_granted(self, permission, granter):
>         if (permission,granter) not in self:
>             return False
>         perm_info = self[(permission,granter)]
>         if perm_info == True:
>             return True
>         # process additional perm_info and return True or False
>
> Here, permission_info_obj could be anything, and may be per
> permission, with a permission requiring special processing
> providing also a check function to be called with the
> perm_info_obj. For the subscription case I was thinking of a simple
> 2-tuple, (startdatetime, enddatetime).
>
> You feeling is that such a way to go would not be a good idea?

I think that sounds like a reasonable idea, for applications that
need it.
Any particular representation will be better for some applications
than it is for others.   The representation we're using is the one
that we think best fits our actual applications.  If you or other
dulcinea users want fancier Permissions, it will be pretty easy
to do that by putting your own kind of Permissions instances
on your User instances.  Other code may be reusable as long
as your permission instances implement the grant/ungrant methods.

Conceptually, I think permissions can easily get too complicated,
especially for application users.  With this permissions change, we're
really trying to make things simpler.