This sounds more like a versioning problem for the rewriters than something that should be solved via TTL?
The example of a rewriter inlining a script where before it used to create a <Script src=...> tag wouldnt benefit from TTL. In the case of rewriting links to a proxy we do need to be careful to propagate rewriter version changes into the URL to cache-bust if we know in advance that the referenced content will now be rewritten differently On Thu, Sep 18, 2008 at 1:16 PM, John Hjelmstad (JIRA) <[EMAIL PROTECTED]>wrote: > 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. > >
