> From: Amir Rosen [mailto:[EMAIL PROTECTED]] > > > -----Original Message----- > > From: Vadim Gritsenko [mailto:[EMAIL PROTECTED]] > > Sent: Tuesday, August 13, 2002 2:35 PM > > To: [EMAIL PROTECTED] > > Subject: RE: Cachable Readers > > > > > > > From: Amir Rosen [mailto:[EMAIL PROTECTED]] > > > > > > Ok, > > > Do you think this behaviour is going to be changed (fixed) soon > > (someday) ? > > > > Amir, > > > > Caching works a bit different from what you think. > > > > > > > > From: Carsten Ziegeler [mailto:[EMAIL PROTECTED]] > > > > > > > > Amir Rosen wrote: > > > > > > > > > > Ok, now it's my turn not to understand :) > > > > > How do I access the cached object ? > > > > Cocoon caches *results* produced by the cocoon pipeline (with validity > > object - see below). It does not caches cocoon pipeline components > > itself, because they are pooled and *reused*. > > > > > > > > Ah, a weak point - yes, you're right you don't have > > > > access to the cached object. > > > > And it is not needed. Sitemap component is given all the > > information it > > needs (in setup method) to re-create situation which was at the moment > > of creating cached response. After that, (cacheable) component is able > > to tell on what external / environmental conditions depends > > its output, > > and generates validity. > > > > To determine whether response which could be generated right now is > > different from the response generated some time ago and cached, these > > validity objects are compared. If there were no changes, then Cocoon > > takes cached response and *re-plays* it, like a sound record, > > *without* > > using sitemap component. > > > > I absolutely agree with your description of the caching mechanism, only > it doesn't exactly work that way for readers (which was my point for starting > this thread). > > Readers generate 3 things that should be cached: the mime-type, the last > modified > date, and the binary output. When a validity check causes the use of a cached > output > from a reader, all these 3 should be used from the cache, and not like it > works > now, that only the binary data is used from the cache, and the other two are > generated again from the newly setup()ed reader.
Aga! Yes, you are right, it totally makes sense to cache these together with binary output. CachedStreamObject and CachingStreamPipeline (2.0.3 - speak) should be modified to accommodate this. Vadim > Amir > > > > > > > Do you mean I should Implement the caching by myself ? > > > > You need only to create Validity object, which can store any > > information > > you need. Just make sure you have comparison method and your > > validity is > > Serializable (cache lives longer then Cocoon instance!). > > > > > > No, I thought it would work the other way. So, if you > > > > really need this feature (accessing the cached object), > > > > As pointed out above, there is no notion of cached *object*, but there > > is cached *result*, which is set of XML events (or bytes), plus > > validity. > > > > > > > > you have to take care of the caching yourself. > > > > It's enough to take care of validity object. > > > > Vadim > > > > > > Carsten --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
