> -----Original Message-----
> From: Vadim Gritsenko [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, August 13, 2002 3:25 PM
> To: [EMAIL PROTECTED]
> Subject: RE: Cachable Readers
>
>
> > 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
>
THANK YOU
So, what's the procedure for changing that ?
Who's handling this functionality ?
Amir
>
> > 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]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
