Re: [Zope-PAS] PAS Caching (sucks)
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
Re: [Zope-PAS] PAS Caching (sucks)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 29 Jul 2006, at 11:44, Sidnei da Silva wrote: | 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. Same here. I am fine with the use of ZCacheable. It also can be used with other cache implementations, for example the MemcachedCacheManager to share the cache between multiple instances. OK, no problem. I won't harp about it again. Still hate it. ;) jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Darwin) iD8DBQFEzNEhRAx5nvEhZLIRArhzAJ4io/iRmdIGzlNz6jvmHU1hD6E/iACdHWd1 048di+XZ7Z2O704kLkOH6M8= =zb5V -END PGP SIGNATURE- ___ Zope-PAS mailing list Zope-PAS@zope.org http://mail.zope.org/mailman/listinfo/zope-pas
Re: [Zope-PAS] PAS Caching (sucks)
On Sat, Jul 29, 2006 at 11:02:10AM -0400, Chris McDonough wrote: | Hmmm.. PAS' trunk PluggableAutheService class already inherits from | OFS.Cacheable and its _findUser method uses the available cache, so | it seems like what you want when you say "caching should be applied | at the 'gateway' into the user folder, where it emits user objects" | already works. "Thread independence" is a property of | RAMCacheManager already. | | 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. Same here. I am fine with the use of ZCacheable. It also can be used with other cache implementations, for example the MemcachedCacheManager to share the cache between multiple instances. -- Sidnei da Silva Enfold Systemshttp://enfoldsystems.com Fax +1 832 201 8856 Office +1 713 942 2377 Ext 214 ___ Zope-PAS mailing list Zope-PAS@zope.org http://mail.zope.org/mailman/listinfo/zope-pas
Re: [Zope-PAS] PAS Caching (sucks)
On Jul 29, 2006, at 10:28 AM, Jens Vagelpohl wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Even though I am the perpetrator, I think the current way of caching, using ZCacheable and RAM cache managers, is absolutely horrific. It's cumbersome to set up and the ZCacheable API is ugly as sin using it from code. I think simplification is needed. 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. This model is the exact same model used in the LDAPUserFolder itself. The caching mechanism in the LDAPUserFolder contains two thread-independent "bags" where unwrapped users are stored: One exclusively for user objects generated from "passwordless" lookups, such as calls to getUser or getUserById and friends, and those generated by lookups that provide passwords. In this particular application having two user caches is simply an artifact of my slight abuse of getUser, so it might end up different in PAS. Who's got an opinion? Hmmm.. PAS' trunk PluggableAutheService class already inherits from OFS.Cacheable and its _findUser method uses the available cache, so it seems like what you want when you say "caching should be applied at the 'gateway' into the user folder, where it emits user objects" already works. "Thread independence" is a property of RAMCacheManager already. 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. - C ___ Zope-PAS mailing list Zope-PAS@zope.org http://mail.zope.org/mailman/listinfo/zope-pas
[Zope-PAS] PAS Caching (sucks)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Even though I am the perpetrator, I think the current way of caching, using ZCacheable and RAM cache managers, is absolutely horrific. It's cumbersome to set up and the ZCacheable API is ugly as sin using it from code. I think simplification is needed. 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. This model is the exact same model used in the LDAPUserFolder itself. The caching mechanism in the LDAPUserFolder contains two thread- independent "bags" where unwrapped users are stored: One exclusively for user objects generated from "passwordless" lookups, such as calls to getUser or getUserById and friends, and those generated by lookups that provide passwords. In this particular application having two user caches is simply an artifact of my slight abuse of getUser, so it might end up different in PAS. Who's got an opinion? jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Darwin) iD8DBQFEy3CIRAx5nvEhZLIRArwVAJ9V4hJ6dR4B7CE7p7E/v56oaolL+QCfX3OQ yJmjbx2cNCSp2KFBEMTveLo= =meix -END PGP SIGNATURE- ___ Zope-PAS mailing list Zope-PAS@zope.org http://mail.zope.org/mailman/listinfo/zope-pas
