[Zope-PAS] PAS Caching

[Jens Vagelpohl]

> Maybe we could change the implementation of RCM's ZCache_invalidate to
> accept a path too?  There's no reason to need to traverse to the object
> and call its ZCacheable_invalidate, we already know the path of the
> thing we want to invalidate.  The path is the key into the cache 
> entries
> dict so we can still get the cache entry object, and even if the object
> has disappeared (or wasn't ever there, sometimes it's desirable to 
> cache
> things that aren't persistent objects) we should still be able to
> invalidate any cache entry.
>
> If the only reason for PRCM is per-entry invalidation, I'd really like
> to see that feature added to RCM proper (and see PCRM ditched).  Are
> there other reasons?

One of the reasons I did not want to touch RAMCacheManager itself is 
simply the fact that I didn't want to tell the customer to run some CVS 
checkout of Zope in order to make this work. Your argument is perfectly 
valid otherwise. What I'll do is indeed change RAMCacheManager and 
apply the "enhancements" there. If the customer does not want to use a 
CVS checkout I'll build a monkeypatch product.


> Also, caching the user object proper in _findUser is probably an
> accident waiting to happen.  The PAS API doesn't specify that the user
> object can't be persistent (it's not in the default implementation, but
> a plugin can do whatever it wants), and caching a persistent object in 
> a
> module-level global is bad news.  If we put this code in there, we need
> to make it clear that the contract of createUser in IUserFactory is
> required to return non-acquisition-wrapped, non-persistent objects.

The code already does a aq_base on the user before storing it, so 
that's not a problem. As far as the persistent user goes, IMHO that's a 
bridge I will cross when we get to it.

jens