cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sergio Carvalho <scarva...@criticalsoftware.com>
Subject Monitor handling unknown timestamps
Date Wed, 03 Jan 2001 00:26:15 GMT
Hi,

This is a bit long (sorry), but important. Please read it, and advise, so I can solve my problem
and submit a patch back to Cocoon.

Motivated by a few hickups with caching and the Xinclude processor, I've been around the Cocoon
code for a while (congratulations, it's excelent :-). Anyway, I think I pinned down my problem
to a resource monitor (org.apache.cocoon.framework.Monitor) design flaw. Specifically, with
the hasChanged method (public boolean hasChanged(Object context)).

The method is a boolean, which seems at first correct. The problem is that this definition
doesn't handle unknown timestamps. I'll give an example with my own problem: I use xinclude
to create the initial XML datafile from other HTTP sources. These HTTP requests have no Last-Modified
HTTP header field. Since the Monitor relies on these (via URLConnection.getLastModified method)
to determine whether the resource has changed, it will assume the resource is still valid
(as per the JDK docs, in the absence of a Last-Modified header, getLastModified will always
return 0). Even if the http response is different, the Monitor will say it's still valid and
the Xinclude processor will, correctly, avoid reparsing everything.

So, I'd like to have the Monitor be honest, and say I_DONT_KNOW when I ask if a resource has
changed and it can't answer me. Then, each Monitor user can decide whether it wants to be
conservative and regenerate the page, or audacious, and get the cached version. Something
like a "public int threeStateHasChanged(Object context)", 

As a side note: I already tried changing the current default behaviour of the monitor to conservative
(by default, it assumes the resource has changed), but processing then takes very very long
(30-60 seconds). I didn't investigate, but it was probably invalidating internal stuff like
pre-parsed stylesheets.

I'd like a review on my analysis. If it proves correct, I'll add the new method to the Monitor,
document or deprecate the old one and change the xinclude processor. 

Thanks for any feedback,

--
Sergio Carvalho
---------------
scarvalho@criticalsoftware.com

If at first you don't succeed, skydiving is not for you

Mime
View raw message