I think I'm close to a compromise solution that will continue to use md5sum digests, unless the incoming path resource is "unprotected".
The caching is something I'll have to work in as well. I'm hoping that i'll be able to do a File(URL.getFile()).exists() on the path returned by the resource and then doing an actual last modified check on it to determine the caching. This would apply to unprotected resources only, which hopefully won't even be requested by most modern browsers if they are functioning correctly. (FF recently fixed caching on async io requests so that should cover IE and FF at a minimum ). I tried adding a unit test to compare execution time htis using the new methods but either my box is too fast or the algorithm hit so low that there is no discernable difference. (the test does assert that the runtime isn't at least slower so it'll be easily pegged if the runtime performance increases on a slower box than mine) On 12/27/05, Howard Lewis Ship <[EMAIL PROTECTED]> wrote: > > One of the advantages of the md5 encoding is that, for a file on the > classpath (a virtual file system) ... when the contents of a file > change, the path changes (since it incorporates the md5 sum of either > the old or new version of the file). This is very useful, since > Tapestry encourages the client to aggressively cache the file's > content, knowing that any change will become, in effect, a new file > with a new path. > > On 12/27/05, Leonardo Quijano Vincenzi <[EMAIL PROTECTED]> wrote: > > You can leave sensible defaults, but then you'd need to include some > > sort of DENY / ACCEPT logic for people to override (mostly for > > completeness). > > > > -- > > Ing. Leonardo Quijano Vincenzi > > DTQ Software > > > > > > Jesse Kuhnert wrote: > > > I like that one as well. A compiled regexp pattern for each > unprotected > > > resource spec will also help the possible performance hits. > > > > > > I guess in the interest of configurability tapestry won't be able to > have > > > anything unprotected by default, except perhaps for those resources > tapestry > > > itself uses. > > > > > > Does anyone see a need to ever protect css/js/image files like this? > I'd > > > like to make everything as configurable as possible, but if this > config spec > > > starts to grow unwieldy that wouldn't be pleasant either. > > > > > > I'll leave everything protected for now.. > > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > -- > Howard M. Lewis Ship > Independent J2EE / Open-Source Java Consultant > Creator, Jakarta Tapestry > Creator, Jakarta HiveMind > > Professional Tapestry training, mentoring, support > and project work. http://howardlewisship.com > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
