On 12/11/06, Alec Mitchell <[EMAIL PROTECTED]> wrote:


This code isn't about a RAMCache which lives across threads and
requests, but is a short-lived cache which is bound to a particular
request.  It's purpose is to make multiple calls to the same

I feel that I understand how this solution is currently implemented. :)

methods/attributes in a given request use the same data, e.g. to
relpace the elemts in global_defines (now @@plone/globalize) with a
more general, transparent, and reusable way of making potentially
expensive calls repeatable for a given request.  It would certainly be

I feel that I understand the goal of this solution. :)

possible to use a RAMCache for this but it would probably be overkill,
simply because it would be need to be keyed in a very general way (per
user, per context, per view, possibly per time of last content change
for navigation related methods).  In other words, if we were using a

This is incorrect.  If we are storing generated values based on:

 (context, view_name, method_name, keywords)

This is an entirely acceptable key for:

 Zope2 RAMCacheManager
 Zope3 RAMCache
 MemcachedManager, which could be based on either of the above

Keep in mind, esp with AJAX, that some requests to the same context
referring to similar data may hit different zope clients and/or
threads.

So, I understand that it may sound like overkill, but I'm disagreeing.
Of course, I understand that I may have to choose between writing
code myself and seeing nothing come of the discussion, but I think
it's an idea worth exploring.

more general cache we'd need to use a much different and more complex
set of keys.  Of course, these cache decorators can easily be
rewritten at any time to use a different storage mechanism if that
turns out to be desirable, probably with no changes needed to code
that makes use of them.

The keys are bound to the context and the perspective from which it is
being accessed, not the request, and there's no reason they should be
request-specific.

It may be necessary to also use roles in the key, but in comparison
with a hash of the context and all arguments to a method, that's
probably minimal.

There is some concern that memcached may have a limit on cache key
sizes, but it's a very simple C app and could probably be extended
easily.

--
Justizin, Independent Interactivity Architect
ACM SIGGRAPH SysMgr, Reporter
http://www.siggraph.org/

_______________________________________________
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

Reply via email to