One problem which we have with all these things is that we need to integrate it in the build system. The complete demo section publishing works through the Makefiles checked in the SVN. We need to manipulate them to do it. And we need to be sure that the build versions (release archives) don't contain any web server specific stuff.
If you can send patches to the build system or can made suggestions how to implement this we would be happy. BTW: You can also download the API viewer completely built using the "built" archives downloadable at sourceforge. Offline is always the fastest :) Sebastian Hugh Gibson schrieb: >> One thing to be careful of here is the period for which the browser >> thinks that the file is valid. This is specified from the server >> when sending the file using the headers: >> "Cache-control: max-age=xxx" where xxx is the maximum age in >> seconds and/or >> "Expires: <date/time>" > > I see that this hasn't been done. It's a simple change but makes a huge > impact with modern browsers. It's also essential before deploying as at > present there is nothing to tell the browser when to mark its cache of > data about each class as dirty. > >> Looking in Firebug at the devel apiviewer I only see the headers: >> >> Date Sat, 16 Jun 2007 06:30:56 GMT >> Server Apache/2.2.3 (Debian) PHP/5.2.0-7 >> Last-Modified Wed, 06 Jun 2007 08:30:51 GMT >> Etag "2464039-1459-9da164c0" >> Accept-Ranges bytes >> Content-Length 5209 >> Keep-Alive timeout=15, max=97 >> Connection Keep-Alive >> Content-Type application/x-javascript >> >> For more information on setting this up, >> http://www.improvedsource.com/view.php/Web-Performance/38/ appears >> to be relevant. >> >> Note that you should do this before deploying the devel api viewer >> to current, as otherwise the data files might be cached too >> aggressively by browsers. > >> Even setting a very short timeout can have a significant impact, as >> it means that the "304 - not modified" response is sent back from the >> server which means that bandwidth isn't used. > > 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. > > The impact on the demos will be similarly dramatic - returning to them > will be almost instant if they haven't changed. > > Sorry if this is teaching my grandma to suck eggs - but I feel that you > are missing a trick here. > > Hugh > > ------------------------------------------------------------------------- > 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 ------------------------------------------------------------------------- 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
