On Mon, 15 Nov 2004, Peter Hunsberger wrote:
On Mon, 15 Nov 2004 19:45:42 +0100, Carsten Ziegeler <[EMAIL PROTECTED]> wrote:<snip/>Peter Hunsberger wrote:
I'm currently reworking our system to add finer grained cache normalization and I'm a tad confused as to exactly how Cocoon checks cache validity. In particular, as the subject line says, I can't see why the SourceValidity class needs the capability to check against a new SourceValidity?
This method is required if the source validity can't tell by itself if it is still valid. For example, if the source validity stores a last modification date of a file (an http request etc.), it can't tell by itself if the resource has changed. In this case the new (current) last modification date is required and the implementation of the source validity would check if they are the same or not. We used to use this for our file based validities for example, until someone had the clever idea to store the file object into the source validity. But if you would only store the last modification date, you need this method.
I'm still confused:
1) Why can't the validity itself figure out whatever it needs to know. Eg, go look at the file to see if has been modified?
Becasue the SourceValidity is just a Validity not the resource the validity is about.
2) Who generates the new source validity for the second check? I can't see how sequence of methods would be actually invoked...
Either a client class using/managing a resource or the resource itself.
Storing all the knowledge the validity needs to determine validity within the validity itself seems like the only thing that makes sense?
Well, depends on the POV. The Validity is all about validity checks not about producing them.
So, in the general this method is imho needed ;)
I'll take your word for it, perhaps the real question is, if I'm implementing a caching generator what do I really need to worry about?
-- Giacomo Pati Otego AG, Switzerland - http://www.otego.com Orixo, the XML business alliance - http://www.orixo.com
