[Zope-dev] RAMcache and container vs. context

[Paul Winkler]

On Mon, Apr 25, 2005 at 03:19:42PM -0300, Leonardo Rochael Almeida wrote:
> Sorry for comming late into the fray :-)
(snip)
> This alternative won't help you when:
> 
>   * the pythonscript is sensitive to the context AND
> 
>   * it is called w/ 2 or more different contexts on the same request
> 
> An artificial example I can come up w/ from the top of my head: 
> Suppose you have a folder w/ an index_html that displays information
> about it's subfolders that is calculated by an expensive script and you
> want to cache the results of this script, you'd go:
> 
>         <ul>
>          <li tal:repeat="subfolder python: here.objectValues('Folder')">
>           Folder <span tal:content="subfolder/title_or_id"> contains
>           <span tal:content="subfolder/expensively_calculate_shruberries">
>           shruberries.
>          </li>
>         </ul>
> 
> Then you'd go and RAMCache "expensively_calculate_shruberries"
> 
> But if we implement the change you're suggesting, then this page would
> list the same number of shruberries of the first subfolder for all of
> them.
> 
> -1 from me

OK, and now that you've said all that, -1 from me as well;
I think the idiom you describe is very common.

That's why I like to discuss things on the list before filing
collector items :-)

I kinda wish the RAMCache manager allowed other things than
REQUEST variables for differentiation. Arbitrary TALES expressions
would be nice. Then we could get rid of this hard-coded gunk and
get the same effect by having context/getPhysicalPath as one
of the expressions.

But of course then you'd have the opportunity to kill your
cache performance by making the expressions too expensive.
Ah well, TANSTAAFL and all that. I'll probably just drop the idea.

> > For a related annoyance, see:
> > http://www.zope.org/Collectors/CMF/343
> 
> This annoyance is indeed related, but the proper fix is for
> FSPythonScript to have a ZCacheable_manage page that takes into account
> the fact that it's usually part of a portal_skins setup and deal with
> it. Alternativelly, portal_skins should provide the functionality of
> expiring RAMCached subitems.

Of those, I'd prefer the latter approach. Added this as a comment
to #343.

Thanks for the valuable input!
 
-- 

Paul Winkler
http://www.slinkp.com