*.cache.xml and other GWT generated files

[Jason Essington]

Perhaps someone more in tune with GWT can answer this one for me ...
Scott maybe?

The *.cache.xml files generated when compiling a GWT appear to hold
information about generated classes (service proxys and field
serializers) as well as about deferred binding decisions.

As far as Web mode goes, this information seems to be irrelevant
because those classes/decisions will have already been incorporated
into the *.cache.html files.

Is my assumption here accurate? Are the *cache.xml files ever used
for anything in web mode?

are the *.cache.xml files only used by the hosted mode debugger?
Or are they simply remnants of the compile process much like the
files produced from the -gen switch?

I'm just trying to get a full picture of all the files that gwt
produces.

So far, here's what I have:

gwt.js <- bootstrap script
xxx.nocache.html <- traffic cop used for resource injection and
loading the platform/internationalization specific *.cache.html file
*.cache.html <- actual javascript payload optimized for a particular
platform and internationalization
*.cache.xml <- notes to the hosted mode debugger about compiler
decisions ???

Is my list here even remotely accurate?
Are there any other files that GWT will produce that I haven't seen?

Thanks for any information you can provide.

-jason

[mP]

Why does it matter ?

[Essington]

mP wrote:
> Why does it matter ?

It matters mostly because I really need to know what the purpose of
every file is. This is especially true when deploying to a production
environment.
Forgive me if I am a little leary of deploying any thing I don't
understand to my production servers. Especially deploying something I
don't completely understand into a publicly accessible path on my
production servers.

I don't think it is too much to ask to have the purpose of all the GWT
generated files explained.

-jason

[Luciano Broussal]

Hi you have one cache.xml by browser (1 for ie , FF , opera ...)

[Jason Essington]

On Oct 11, 2006, at 8:54 AM, Luciano Broussal wrote:

> Hi you have one cache.xml by browser (1 for ie , FF , opera ...)

yup, and they have hashed names that mirror their cache.html cousins.
That part I get.

The part I would like to have verified is that they serve no purpose
in "web" mode.

-jason

[Bruce Johnson]

Hi Jason,

The short answer...

The *.cache.xml file are used only during the compilation process and do not need to be deployed. They aren't used in hosted mode at all.

The slightly longer answer...

They are metadata that tell the compiler which permutations have already been compiled. You can think of them as complex cache keys, where each key is a set of (type => class) mappings and each value is a particular *.cache.html file that should be served when that mapping applies.  Each GWT.create(T.class) call gets an entry in the *.cache.xml file that says how T gets mapped for that particular compilation. There are as many unique *.cache.xml files as there are unique permutations, all of which stem from the use of GWT.create() calls.

And you are correct that the information in the *.cache.xml files is burned into the *.nocache.html files, which is why you don't need to deploy the *.cache.xml files.

Parting thoughts:

1) Either don't cache *.nocache.html files or make them expire more quickly than you update your app. In other words, you never want to have a client with a cached *.nocache.html requesting *.cache.html files that no longer exist on your server. The *.cache.html files are named with MD5 hashes so that they can never be confused with each other.

2) The pay off for #1 is that you can (a) gzip your compiled script files ahead of time and, even better, (b) cache the *.cache.html files forever. Really...make them expire when the sun explodes. This is great because after the first download, the browser doesn't even have to do a "If-Modified-Since" HTTP round-trip.

If you get it right, you can have really fast startup. In other words, the very first load should look like this:

1) Request host page HTML
2) Request gwt.js (gzipped unless client is IE; cacheable for a long time)
3) Request <module>.nocache.html (ideally gzipped; only cacheable for a short while or not at all)
4) Request <md5>.cache.html (ideally gzipped; infinitely cacheable)
5) Start

and subsequent loads should look like this:
1) Request host page HTML
2) If cache period expired, check "If-Modified-Since" for gwt.js (cacheability on how often you plan to deploy updates)
3) If cache period expired, check "If-Modified-Since" for <module>.nocache.html (cacheability on how often you plan to deploy updates)
4) Start

Hope that helps.

-- Bruce

[Jason Essington]

Thanks Bruce!

That is exactly the information I was hoping to hear.

-jason

[JR]

Is that true? my gwt.js includes this code. Seems to me the nocache
files are used in web mode, no?

//////////////////////////////////////////////////////////////////
// Web Mode
//
function __gwt_injectWebModeFrame(name) {
if (document.body) {
var parts = __gwt_splitModuleNameRef(name);

// Insert an IFRAME
var iframe = document.createElement("iframe");
var selectorURL = parts[0] + parts[1] + ".nocache.html";
iframe.src = selectorURL;
iframe.style.border = '0px';
iframe.style.width = '0px';
iframe.style.height = '0px';
if (document.body.firstChild) {
document.body.insertBefore(iframe, document.body.firstChild);
} else {
document.body.appendChild(iframe);
}
} else {
// Try again in a moment.
//
alert("4");
window.setTimeout(function() { __gwt_injectWebModeFrame(name); },
__gwt_retryWaitMs);
}
}

[Jason Essington]

right, the *nocache.html files are used, but the nocache.xml files
are not

-jason