Forum OpenACS Development: Re: Should we timout permissions cache?

5: Re: Should we timout permissions cache? (response to 1)

Posted by Peter Marklund on 02/08/03 09:44 PM

Don,
thanks for the statistics from SloanSpace and the promising figures for the new optimized permissions API. I look forward to using it!

Jeff,
I guess that for my homepage at least b) and c) apply, and maybe even a) 😊

I would have to test the optimized API to really tell, however, it still seems to make sense to me to cache permission_p. For instance, permission_p is invoked at least once per request by the request processor on the requested package instance. I like the fact that on my homepage I now have zero over head queries invoked by the request processor.

I'm maybe missing something, but I don't see why caching is so fragile. Aren't packages using the Tcl API to grant and revoke permissions? If not, how hard would it be to make them do that?

6: Re: Should we timout permissions cache? (response to 5)

Posted by Jeff Davis on 02/08/03 11:00 PM

Peter, the thing you are missing is that in a lot of cases (in fact almost every case) the permission is not granted directly, a given user has or doesn't have it by virtue of being in the right group and the object generally inherits the permission from another object.

To get it right, if you add or remove someone from a group you would have to flush all permissions for that user (strictly speaking you might be able to hold on to some but I think that would cost more than just flushing them all). If you change permission on an object you would need to flush all the ones on that object or any object that inherits permissions from that object.

As it stands, granting and revoking direct permissions via the tcl api will flush properly, and I made a couple other operations flush as well but really getting it right is quite hard.