[
https://issues.apache.org/jira/browse/SHINDIG-616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12632452#action_12632452
]
John Hjelmstad commented on SHINDIG-616:
----------------------------------------
Returning caching directives on a per-rewrite-operation basis also allows
caching of partially-rewritten data.. that's not implemented, but in any case
this info needs to be known.
> 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.
