I'm not sure I follow -- the same version of a given rewriter might do: * At time T0: <script src="foo.js"/> --> <script>contents of foo.js at time T0</script>
* At time T1: <script src="foo.js"/> --> <script>contents of foo.js at time T1</script> The rewriting algorithm, code implementing this, and input hash are all the same -- all that differs is Tx. We don't know in advance what a given script tag's validity will be, so I'm not sure how we would inject a rewriter version. Thoughts? John On Thu, Sep 18, 2008 at 6:16 PM, Louis Ryan <[EMAIL PROTECTED]> wrote: > 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. > > > > >
