Hugh Gibson wrote: > Just to clarify this point: I suggest that you specify a small timeout > e.g. 1 minute. Obviously the viewer caches data files itself in that they > are only loaded as required. Therefore the small timeout has no effect > during a single session of using the API viewer. However, if the user > navigates away then back to the API viewer, the browser will check with > the server whether each data file (as well as the main script!) is still > valid by sending the local date/time. The server checks if the file has > been modified since then, and if not, sends back the "304 Not Modified" > response. The browser can then use the local copy. This dramatically > reduces the load on the server, and also ensures that any user will be > using the latest data files within a very short time of them being > deployed. >
Cache headers and compression are now implemented on the demo.qooxdoo.org web server. - The cache header returned by the web server look good to me. I set a default expiration of 1 day, and the suggested 1 minute for Javascript files. - My tests (with FF) suggest that there is really no harm in such a short expiration period. This browser even makes requests *before* the 60 seconds are over, just to receive the 304 response code. I think that's not an issue for the web server. Nevertheless, I'd be happy if people keep an eye on that and report back any issue they might encounter. - On-the-fly compression is enabled with mod_deflate. As far as I can see it looks good, but I'm concerned about the 'old browser' issue. I have none of those (ugly) additional Apache config directives in place of the kind "BrowserMatch ...", since the heuristics look fairly fragile to me. So currently mod_deflate just uses the 'Accept-Encoding' request header to decide whether to compress or not (I believe). If this brings up any kind of problem please let me know and I commit to the BrowserMatch thingies. - I'm also interested on qualified feedback on the over-all performance in the api viewer under the new scheme, especially when slow lines are involved. > Sorry if this is teaching my grandma to suck eggs - but I feel that you > are missing a trick here. > > I for my part are quite happy that you made that point, and on that level of detail ;-). Also thanks to the other people on the list who provided all the good links and details. You saved me hours of research. Cheers, =Thomas ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ qooxdoo-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
