It all depends on what the rewriter that generates the script tag decides to do
Why would an HTML rewriter not just exclude a rewrite of foo.js so it is not passed through the proxy and the browser respects its cache headers which should represent its temporality? If client need precise control over the TTL of foo.js in the browser they should definitely not use a proxy. If a rewriter has *internal* knowledge that a version of a referenced resource changes over time and wants to represent that in the output that is something entirely different, then yes it would need to eiter control the internal cache TTL or there should be a rewrite phase on output. At some point it may become necessary to compile gadgets into a more compute-efficient and cacheable templating language which can accomodate the injection of custom outputters. Hell a linked list of Strings and functions would do just fine. In the meantime I think Im fine with adding the TTL handling. Ill take a look at the code later. On Thu, Sep 18, 2008 at 6:36 PM, John Hjelmstad <[EMAIL PROTECTED]> wrote: > 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. > > > > > > > > >
