On Oct 8, 2005, at 5:09 AM, mario ruggier wrote:

> Thanks. It is very nice and simple. A few comments:
>
> While we are talking about names, should'nt that be "grantee" and
> not "granter" ?
> Just to clarify, what grant() does may be simply said:
>     Subject (user self) : Verb (permission) : Object (receiver of
> the allowed action)
> And, when object is just True, then the subject is granted the
> permission open-endedly...

I think of it in the other way, the user is the receiver of the
permission.
The permission originates with the other object.  It is the other object
and the ui that deals with it that that defines what the permission
means.

>
> Plus, what about revoke instead of ungrant?

I like either, but I think I can remember ungrant() better, here.

>
> For expiring permissions (such as valid paid subscription), one
> would need to customize is_granted(), e.g. to call a specific
> function that checks the validity of the permission? So, persisting
> this info does not seem like such a good idea... Unless, a
> permissions can be scheduled, e.g., with a start and end date, the
> is_granted() check can therefore be self-contained. And how the
> start and end-dates are set will be external application logic.

Permissions won't be appropriate for every situation.
I would not customize is_granted(), ever.  Instead, I would
write more narrowly defined predicates like "is_subscribed()"
that do what is needed in that situation, either using permissions
or not.