According to Chris McDonough:
> On Jul 29, 2006, at 10:28 AM, Jens Vagelpohl wrote:
> > I personally don't see any need to have caching in plugins
> > themselves. Instead, caching should be applied at the "gateway"
> > into the user folder, where it emits user objects. These user
> > objects should be cached as a whole. I am envisioning a thread-
> > independent cache (meaning no redundant lookups in each thread)
> > that is configured using a caching ZMI tab on the PAS instance. No
> > more Cache tab everywhere and no more RAM cache managers to
> > configure. And no more contortions in plugin code to utilize
> > ZCacheable.
+1 on caching in the "gateway".
> > Who's got an opinion?
> Hmmm.. PAS' trunk PluggableAutheService class already inherits from
> OFS.Cacheable and its _findUser method uses the available cache, so
_findUser can be configured to use a cache, but _extractUserIds can
not. It would be cool if also _extractUserIds could use a cache, since
the authentication step takes place in there.
> You do still need to configure the PAS instance to actually do
> caching. But this seems OK. I think you can just ignore caching
> when creating plugins if this is all you want. Even though the
> ZCacheable API sucks, the indirection here is good. I wouldn't want
> PAS itself to have a hard-wired caching implementation in it, and I
> don't mind associating the PAS instance with a cache manager.
Nevertheless i think to PAS Caching needs improvement. Currently there
is no way to cache the authentication step in the "gateway".
[EMAIL PROTECTED] Fax: +43/1/31336/9207
Zentrum fuer Informatikdienste, Wirtschaftsuniversitaet Wien, Austria
Zope-PAS mailing list