[Seaside] [YSlow] How to set expires in response header for css and js resources?

[Sebastian Sastre]

Hi there,
 
    I was able to make Seaside to write files to disk in an optimized
fashion. In the application config it offers you to save all the files of
the libraries in a configurable subfolder of the image directory or make
that but in an optimized version.
 
    In the optimized version (you should set your current/next version
string) it collects all the CSS content of the libraries used by the
application and writes in a single css file. The same is made for javascript
content. 
 
    The version string is concatenated just before the extension of the
filename like this:
        <filename>.<version string>.<extension>
        Ex.: 
            cssStyle.1.3a.css 
            javascriptStaticCode.1.3a.js
 
    With that, if you use them, scriptaculous, prototype, your own js stuff,
goes to that .js file wich probably will be better deflated or gziped by
modern http servers.
 
    I saw a couple of metrics on a site of my own. I show a table of results
in the attached file.

    This convinced me to having a package that makes Seaside work like this
is worth. But I also think that Seaside itself deserves it because it makes
it won an A for YSlow principle number 3 sistematically for all pages (valid
for the resources css and js only).
        
    But Yahoo makes the versioning name part of the deployment so I thought
that we also should be able to do it. Why them do that? They do that because
like that they take advantage of the web browsers cache. They add
systematically expiry headers for every static content they serve. So why we
shouln't?

	To implement a systematic optimization like that we need to add the
expiry header for the css and the js files.

	As they are inserted in the updateRoot: which is a process part of a
response that explicitely needs a cache control of "no cache" I don't
understand yet how we can set the expiration of only this two files and not
the rest of the html code. Can someone give me a glimpse on how to achieve
this?

	A secondary question also arrives: can we extend this systematically
to all the resources? Png, jpg, gif, etc having the <version string> subfix
and an expiry date far ahead on time to be able, as Yahoo do, to deploy
anytime a next version of all the resources the seaside app uses in an
inexpensive fashion?

	For your application code should not be a problem if you manage
resource evocation with Jetsam. We should be easily able to make Jetsam
FileLibrary to automatically refer with a proper filename subfix versioned
like your application configuration says that has to use.

	If we could do this we additionally will won an A for YSlow
principle number 3 guaranteed for all seaside components systematically. So
all Seasiders (and users and customers) won.

	cheers!
 
Sebastian Sastre

-------------- next part --------------
A non-text attachment was scrubbed...
Name: libraryDeploy.PNG
Type: image/png
Size: 20470 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/seaside/attachments/20070824/ad7717c0/libraryDeploy-0001.png