The RAMCacheManager is associated with (what I call) site building objects (those have an identifying URL, for example).
Why do you think that?
"User" objects are not site building.
But in zope, they should always have a url ;-)
The UserFolder is but usual implementations do not inherit "ZCachable" -- and therefore cannot (directly) use the RAMCacheManager.
SUF doesn't need to inehrit from ZCacheable...
When an object supports transparent caching (which would be necessry for a UserFolder), then it must contain code interfacing with a cache manager. I doubt that SUF contains such code...
I think transparency (ie: magic, automagical, and other such bullshit) is bad. Explicit is better that implicit and all that ;-)
But hopefully you see that the questions are difficult for a standard user.
Only if the standard user needs caching, in which case they should understand the choices they're making ;-)
When he uses SUF and determines that caching is needed because authentication and authorization are too costly, he may learn that Z SQL Methods can be cached. Later, he changes some user properties and has to observe that they take effect with a delay (as stale values are cached) and there is no reliable way to flush/invalidate the cache. He may learn that there are CCZSQLMethods the cache of which can be flushed, but he may have had long hours of problems.
That seems entirely natural to me. At any time, he can make choices depending on his current needs without being penalised for previous choices...
With "exUserFolder", he visits the configuration tab and selects "with caching for XXX minutes" -- that's it (unless he uses ZEO).
...which case he gets core confused and is locked into a caching setup which he'd have to recode at the python level to get anywhere with ;-)
-- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
Zope maillist - Zope@zope.org
** No cross posts or HTML encoding! **
(Related lists - http://mail.zope.org/mailman/listinfo/zope-announce