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". \wlang{} -- [EMAIL PROTECTED] Fax: +43/1/31336/9207 Zentrum fuer Informatikdienste, Wirtschaftsuniversitaet Wien, Austria _______________________________________________ Zope-PAS mailing list Zope-PAS@zope.org http://mail.zope.org/mailman/listinfo/zope-pas