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? > > Since the generation of the key is separated from the > retrieval of the validity I can't figure out a use case where > you need to further separate the validity checking? For > Cocoon purposes it seems to me that, at worse, any validity > Cocoon has to deal with may have to wrap some external > validity checks behind a simple isValid() method? Does > Cocoon ever generate a new validity for checking against an old one? > > I suppose the answer might simply be that this is an > Excalibur class that allows for comparisons of validities > across clustered servers or some such thing and that it does > nothing specifically for Cocoon? > 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.
So, in the general this method is imho needed ;) Carsten
