Nevermind, solved my RPC-woes by copying the policy file to the web-
app root. Ugly, but down to 2 requests.
On Aug 7, 8:50 pm, George Georgovassilis <g.georgovassi...@gmail.com>
wrote:
> This occurred to me also when I started cutting down the requests: you
> cannot do the initial selection on the server as HTTP proxies will
> then see only one permutation: the first one that is ever retrieved by
> them.
>
> I've reduced the total number of HTTP requests required to load to
> just 2 (1 for the initial module html and 1 for the .cache.html), but
> as stated earlier, inlining does not work as smoothly as Bruce (and
> for that matter, me also) wants it to. First you have to (manually/ant
> task) change the strings in nocache.js to prepend the actual path to
> XYZ.cache.html, and then RPC will get back to you because
> the .cache.html scripts disagree with the serialization policy about
> the service entry points.
>
> So, is there a clean way?
>
> On Aug 7, 6:03 pm, John Tamplin <j...@google.com> wrote:
>
> > On Fri, Aug 7, 2009 at 11:39 AM, Arthur Kalmenson
> > <arthur.k...@gmail.com>wrote:
>
> > > I don't think firebug counts the initial request to fetch the host
> > > page, so two requests. One for the nocache.js and another for the
> > > cachable HTML. With the inlining of the nocache.js file, you could get
> > > it down to 0 requests if the retrieved page is cached forever.
>
> > Well, since it can't be strongly named (if it was then the page with the
> > link would have to be weakly cached for when it changed), the host page
> > can't be cached forever but it can be cached based on the frequency you
> > might need to update it. Note that you need to keep the old compiled script
> > around for as long as the host page might be cached (and any server
> > resources it might need, which makes server RPC changes difficult), since
> > caches with the old host page will be referring to the old compiled output.
>
> > > Are you saying to inline the generated JS in the host page too? How
> > > could you do that? Don't you need the selector script to pick the
> > > correct compiled version? Maybe I'm just not understanding what you
> > > mean.
>
> > See the example below for how it currently works and the change usign
> > server-side selection.
>
> > The problem is that the browser will fetch foo.html and get the proper
> > compiled output for their browser/locale/etc. An intervening cache, say at
> > an ISP, will then return that foo.html response to a different user with
> > different parameters. As I mentioned in the other message, you have to
> > either make the host page uncacheable (which is only feasible with small
> > compiled scripts) or rely on caches honoring the Vary headers, which is
> > problematic on the Internet in general though might be feasible if you
> > control the network your users use to access it.
>
> > Currently you have a host page, say Showcase.html, that is cached based on
> > the frequency you expect to update it and contains a reference to the
> > selection script.
> > ...
> > <script language='javascript' src='showcase/showcase.nocache.js'></script>
>
> > That then fetches the selection script, which is cached based on the
> > frequency you expect to update the app but with must-validate set and
> > executes in the browser, and chooses a strong-named JS file for the compiled
> > output, say XYZ.cache.html. That file is then cached for 1 year ("forever"
> > according to the HTTP spec).
>
> > In the new scheme, you have a host page that is generated by the server from
> > a template. That is mark cacheable for the shorter of the time you expect
> > to update the host page template or recompile your app, with must-revalidate
> > set. It directly includes a script tag referencing XYZ.cache.html, where
> > the server made the deferred binding decision based on the information
> > available in the request. In the typical case, it will use the User-Agent
> > header and perhaps the Accept-Language header and the locale query parameter
> > in the URL.
>
> > Since the results of the request for Showcase.html now depend on those
> > parameters of the HTTP request, you have to make sure that a cache doesn't
> > return a previous copy served to someone with Firefox to the next guy to ask
> > for it who might be using Safari. One way to do that is to make sure it
> > isn't cached at all (or at least with must-validate), and the other is to
> > rely on the caches to correctly interpret Vary headers so they know that the
> > response you returned may be different if those headers are different. As a
> > side note, it doesn't know that you don't care about the difference between
> > IE 7.0 and IE 7.0.1 (making these up so you get the point), or even the
> > screen resolution that some user agents send in the request, so even caches
> > that accept the Vary header will be less effective. There are other ways
> > around it with newer standards, but even fewer of the caches out there will
> > make use of those features so it will be a while before they are actually
> > useful.
>
> > --
> > John A. Tamplin
> > Software Engineer (GWT), Google
--~--~---------~--~----~------------~-------~--~----~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~----------~----~----~----~------~----~------~--~---
