On Mon, 15 Nov 2004 20:53:14 +0100, Carsten Ziegeler <[EMAIL PROTECTED]> wrote: > Peter Hunsberger wrote: > > 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? > > The validity object is just a value object - it has to be serializable > in order to be stored persistently by the cache. > Sure, you could store e.g. the file name in the object and inside > the isValid() method open the file etc. But what about resources > fetched via http or any other protocol? You start mixing value > objects and controls.
Perhaps so, it's not something we'd run into in our system. in our case we've got a seperate class (and interface) that takes care of the association of the validity with data sources. This class has methods that can directly interegate our cache manager to check validity: it our cache on our side is no longer valid then the Cocoon validity is no longer valid. This may seem like redundant caching, but we have cases where our cache management and invalidation runs orthogonal to Cocoon caching: Eg. objects cached by userid but invalidated by groupid. > > > > 2) Who generates the new source validity for the second > > check? I can't see how sequence of methods would be actually > > invoked... > > > It's the source that generates the validity objects. For example > for a file you end up with a file source object that generates > the validity object containing the last modification date of the > file. > In the case of caching, e.g. the file generator resolves a source > object for the given source and asks this source object for > a validity object. This validity object is then stored in the > cache. With any further request, the validity object is fetched > from the cache and the isValid() method is invoked. If this > method is not able to determine if the cached response is still > valid or invalid it returns the constant for UNKNOWN. If it's > unknown the file generator is asked to deliver a new validity > object which is then passed into the isValid(SourceValidity) > method. Ok, I think this really answers my question. The way our system works we can always check on the first call. In general I think this is true: since the Setup method can resolve a source it could arrange for isValid() to do the same work, but having isValid(SourceValidity) implemented removes the responsibility for coding up the check in every generator that might need it. > > Storing all the knowledge the validity needs to determine > > validity within the validity itself seems like the only thing > > that makes sense? > > > > > 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? > > > :) You just have to implement the correponding interface that > makes the component cacheable. The objects you return by the > methods of this interface should be serializable. If you > implement your own source validity object make sure that either > isValid() works or isValid(SourceValidity) works ;) Just to double check; if isValid() never returns 0 then there's no way isValid(SourceValidity) is going to be called? -- Peter Hunsberger
