Forum OpenACS Development: Re: Should we timout permissions cache?
thanks for the statistics from SloanSpace and the promising figures for the new optimized permissions API. I look forward to using it!
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?
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.