[
https://issues.apache.org/jira/browse/SHINDIG-616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12632417#action_12632417
]
John Hjelmstad commented on SHINDIG-616:
----------------------------------------
Irrelevant in what sense? Irrelevant in that use of that rewriter always
obligates the server to perform a re-parse? Yes -- which could, depending on
the data and the rewrite being performed, call into question the wisdom of
using that particular pass. But parsing cost is still relevant even if
unavoidable... especially so in fact.
> 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.
