Hi Thorsten, Thanks again and apologies for drip-feeding the questions.
In the code I'm looking at it appears the second pipeline has an empty map:generate ie. <map:generate/>. I assume this results in the second pipeline using the output from the first pipeline. That being the case the first component in the second pipeline would be a Transformer whose validity object might not have changed, causing the pipeline to reuse the cached output from that Transformer despite the fact that the xml output from the first pipeline had changed ? Not sure if I am explaining myself very well here, thanks for bearing with me. Cheers, Robin. On Tue, 2011-04-26 at 17:59 +0100, Thorsten Scherler wrote: > On Mon, 2011-04-25 at 09:52 +0100, Robin Taylor wrote: > > Hi Thorsten, thanks for the reply. > > > > > "The default algorithm uses a very easy but effective approach to cache > > > a request: The pipeline process is cached up to the most possible > > > point." > > > > > > > Thats the bit that is not quite clear to me. Does caching take place on > > a per-pipeline basis ? So if I have 2 pipleines, both cacheable, does > > the second pipeline know the state of the cache in the first pipeline ? > > Or does the second pipeline make decisions about caching based entirely > > on its own SourceValidity objects ? > > It is on a per pipeline basis more specific per match, where each match > would contain an aggregation of validities. If cacheable each component > used in the match has to return a VALID otherwise the whole is not > cacheable but cached till the NONVALID component. > > To use a pipe from another you usually use the cocoon:/ protocol in a > src attribute. in this case the returned SourceValidity is a pipeline > validity and returned as such. So the second "knows" the validity > through the SourceValidity and in case it is VALID would used the cached > representation of the pipe/match. > > HTH > > salu2 --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
