Sorry Sylvain, but I don't see the benefits in adding the
build version into the url. IMHO, setting the expiration is inferior to setting
last modified - why would it ever need to expire if we know it hasn't changed.
Also, I'm not sure if expiration without last modified works on all
browsers. We don't need to use the date of the file itself as last modified, it
can be whatever, like the date of the jar. I have a few hours free today, I'll
have a look at it. Let the community decide then what's a better approach. Is
there a bug open on this?
Kalle
Instead of setting the last-modified header, I was working on including the jar build version (in fact, it's hash) in the URL, and setting a long (default one week) expiry.
From: Sylvain Vieujot [mailto:[EMAIL PROTECTED]
Sent: Monday, March 14, 2005 5:39 AM
To: MyFaces Development
Subject: RE: Split (or kill) Extensions filter
So, all the content is cached, and when you change your MyFaces jar, the URL is different.
I think it would be better, as the browser will not even query for the last-modified header, and a query will be saved.
Also, I don't know if we can get the last modified date from a file that's in a jar.
Any comment with this approach ?
As stated on a previously, the code is ready, I just need to get the implementation version.
Right now, AddResource.class.getPackage().getImplementationVersion() return null.
On Sun, 2005-03-13 at 21:06 -0800, Korhonen, Kalle wrote:> -----Original Message----- > From: Oliver Rossmueller [mailto:[EMAIL PROTECTED]] > Subject: Split (or kill) Extensions filter > I'm no longer willing to pay the runtime penalty > ExtensionFilter adds to an application (_javascript_ files > loaded over and over again, in-memory buffering of the > complete response) just for the benefit of 10 minutes of > saved developer time for adding the _javascript_ stuff to the > header of any jsf page. The only problem as I can see with the extensionsFilter is that it doesn't currently send the last-modified header when sending a resource. I've been meaning to patch it when I have some time for that, but I'm more than happy if somebody else fixes it before I have a chance. That saved 10 mins for every JSF developer quickly adds up and I strongly believe that 10 mins is worth saving. > So my plan is to split up ExtensionFilter to MultipartFilter > (in the form it was before ExtensionFilter was introduced) > and ExtensionFilter (just dealing with extensions stuff). > Actually I would like to drop the extensions stuff completely > as I don't see any benefit in having this kind of filter at > hand. We could create a myfaces-resources.jar instead where > we place all the image and _javascript_ resources so it's easy > to add all the resources to your war file by just adding a > zipfileset tag to your build file. > Comments? Objections? Personally, I think ExtensionsFilter is a pretty clever way of loading packaged resources. Please consider evolutionary versus revolutionary approach in this case as well. Kalle
