You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@shindig.apache.org by "John Hjelmstad (JIRA)" <ji...@apache.org> on 2008/09/24 03:13:46 UTC

[jira] Resolved: (SHINDIG-616) TTLs for Caching of ContentRewriter ops

     [ https://issues.apache.org/jira/browse/SHINDIG-616?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

John Hjelmstad resolved SHINDIG-616.
------------------------------------

    Resolution: Fixed

Resolved by r698411.

> TTLs for Caching of ContentRewriter ops
> ---------------------------------------
>
>                 Key: SHINDIG-616
>                 URL: https://issues.apache.org/jira/browse/SHINDIG-616
>             Project: Shindig
>          Issue Type: Improvement
>          Components: Gadget Rendering Server (Java)
>            Reporter: John Hjelmstad
>
> Content from ContentRewriters is cached using a hash of input contents as key. This implies that the operation of each Rewriter is idempotent, consistent over time, and indefinitely cacheable.
> Several examples run counter to this implication. Eg. Rewriter that inlines script previously from a <script src> tag. The script is served with a TTL, which should apply to the rewriter output as well.
> I propose that each ContentRewriter method return an object, RewriterResults, at first with only one field:
> long cacheTtl; // time in milliseconds that the rewriter operation's results may be cached
> (boolean isRewritten is not included since mutability APIs can determine that; boolean isCacheable is equivalent to ttl > 0).
> Receipt of these values allows a ContentRewriterRegistry (performing actual rewriting operations) to make intelligent choices about what to cache, optimizing on timeToPerformRewrite, timeToPerformCacheLookup, and cacheTtl.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.