Mailing-List: contact myfaces-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "MyFaces Development" <myfaces-dev@incubator.apache.org>
Received-SPF: pass (hermes.apache.org: domain of kkorhone@cisco.com designates
 171.71.176.72 as permitted sender)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Split (or kill) Extensions filter
Date: Mon, 14 Mar 2005 10:55:01 -0800
Message-ID: 
 <BA7F50A400AF53449809C74ECDB4A79BEFCA2F@vtg-um-e2k4.sj21ad.cisco.com>
Thread-Topic: Split (or kill) Extensions filter
Thread-Index: AcUoxAELfh4A61opRi+MU7EZa/ovjwAAhWEw
From: "Korhonen, Kalle" <kkorhone@cisco.com>
To: "MyFaces Development" <myfaces-dev@incubator.apache.org>

Thanks for implementing it, but one question, why don't you think last
modified header isn't useful? If the last modified header isn't there
the browser should re-request the page every time even if it's cached
and the url is exactly the same. Consequently, I don't see the added
benefit of keeping the version number in the url. I don't think we
should set the expiration at all.

Kalle=20


________________________________

	From: Sylvain Vieujot [mailto:svieujot@apache.org]=20
	Sent: Monday, March 14, 2005 10:31 AM
	To: MyFaces Development
	Subject: RE: Split (or kill) Extensions filter
=09
=09
	Even though I'm not convinced it's very useful, I added the last
modified header.
	I kept the build version (in fact, the last modified time stamp)
in the URL, as I think this is more efficient. It prevents the browser
from asking the server if the document has expired, as it knows it's
valid for at least a week. It's also safe, as if the lib changes, so
does the URL.
=09
	So this way, we should have the best of both approaches.
=09
	Best regards,
=09
	Sylvain.
=09
	On Mon, 2005-03-14 at 08:58 -0800, Korhonen, Kalle wrote:
=09

		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?
		=20
		Kalle
	=09
	=09

________________________________


			From: Sylvain Vieujot
[mailto:svieujot@apache.org]=20
			Sent: Monday, March 14, 2005 5:39 AM
			To: MyFaces Development
			Subject: RE: Split (or kill) Extensions filter
		=09
		=09
			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.
			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.
		=09
			Any comment with this approach ?
		=09
			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.
		=09
		=09
			On Sun, 2005-03-13 at 21:06 -0800, Korhonen,
Kalle wrote:=20

				> -----Original Message-----
				> From: Oliver Rossmueller
[mailto:oliver@tuxerra.com]=20
				> Subject: Split (or kill) Extensions
filter
				> I'm no longer willing to pay the
runtime penalty=20
				> ExtensionFilter adds to an application
(javascript files=20
				> loaded over and over again, in-memory
buffering of the=20
				> complete response)  just for the
benefit of 10 minutes of=20
				> saved developer time for adding the
javascript stuff to the=20
				> header of any jsf page.
			=09
				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.
			=09
				> So my plan is to split up
ExtensionFilter to MultipartFilter=20
				> (in the form it was before
ExtensionFilter was introduced)=20
				> and ExtensionFilter (just dealing with
extensions stuff).=20
				> Actually I would like to drop the
extensions stuff completely=20
				> as I don't see any benefit in having
this kind of filter at=20
				> hand. We could create a
myfaces-resources.jar instead where=20
				> we place all the image and javascript
resources so it's easy=20
				> to add all the resources to your war
file by just adding a=20
				> zipfileset tag to your build file.
				> Comments? Objections?
			=09
				Personally, I think ExtensionsFilter is
a pretty clever way of loading
				packaged resources. Please consider
evolutionary versus revolutionary
				approach in this case as well.
			=09
				Kalle
			=09