cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Giacomo Pati <giac...@apache.org>
Subject Re: AW: cvs commit: xml-cocoon/src/org/apache/cocoon/components/saxconnector NullSAXConnector.java SAXConnector.java
Date Tue, 10 Apr 2001 07:31:06 GMT
Quoting Carsten Ziegeler <cziegeler@sundn.de>:

> > Paul Russel wrote:
> > 
> > * giacomo (giacomo@apache.org) wrote :
> > > Paul,
> > > Can you explain how this kind of content aggregation works together
> with
> > > caching?
> > 
> > This was the content aggregation implementation we discussed some time
> > ago based on inclusion only -- the include code needs to be cache
> aware,
> > and when we get to that stage, we'll implement it.
> > 
> > > As far as I see caching, there will be an evaluation process going
> on
> > > prior to pipeline production. But a SAXConnector as I understand it
> from
> > > the code will not be able to determine its cachability in any way.
> Tell
> > > me that I've missed something :)
> > 
> > What do you mean by 'cacheability'? All the include code will do is
> pull
> > resources from elsewhere in the sitemap - through existing pipelines -
> > which will already have caching implemented. In terms of working out
> > whether an existing cache entry is valid after the
> IncludeSAXConnector,
> > this will depend on:
> > 
> >  * Whether the pipeline before the IncludeSAXConnector is cacheable
> >  * and whether an included resource is cache safe.
> > 
> > Is there any way around this?
> > 
> > Apologies, but I've been away for a bit, so I'm not sure what's
> changed
> > in terms of caching architecture. 

Don't get me wrong. I'm not against the SAXConnectors concept. I like it 
because it is transparent to the user. I'm only thinking about it loud. Anyway, 
my stand point is that we should stick with caching generator components only 
for the beta and do the transformer/serializer chaching later on.

The caching proposal states that "a component that depends on its input is not 
cachable". Why? Because a component has to express whether its output is 
cachable prior to process its input. This implies that every component that does 
something similar to xinclude cannot be cached. This means that a EventPipeline 
that holds SAXConnectors will not be cachable as a hole. 

If we like to be able to aggregate content similar to the example posted several 
times witch collects header, navigation and content parts together, pull them 
from different cocoon served URIs and have them (or at least the static parts of 
them like the header and the navigation) in the cache we need to eliminate the 
last SAXConnector from the EventPipeline class so that the EventPipeline class 
can state real cachability as a single component (containing only a Generator) . 
And thus IMO this means that we need, as I've proposed earlier, a sematic in the 
sitemap to express aggegation at the sitemap level to pull different cocoon URIs 
together.

> > How are you intending to implement
> > caching? Using the cache key and validator idea, or something else?

In fact both approaches seem to be usable together. The one I've proposed leave 
the implementation to the component expressed by the getKey() and getValidity() 
methods. The one proposed by Ricardo externalizes this into a separate object 
where the component puts the objects into it which are making up the cache key. 
Thus simple implementation can have the getKey() and getValidity() methods 
depend on the proposed method by Ricardo. In terms of speed a simple component 
like the FileGenerator can implement the getKey() and getValidity() method 
themself because it depends only on a String that represents the file to read 
and make the CachePolicy approach somewhat more expensive. My proposal will be 
that a AbstractCachableComponent will have the getKey() and getValidity() as 
well as the fillPolicy() methods where the former two depends on the later. This 
leaves it to the component implementor which one to overwrite. For XSP 
programmers the fillPolicy will be an easier method to use.

> Currently I am reviewing some of the caching discussions. I hope I can
> finish this today and post my first proposal about the caching
> implementation.
> The caching solution seems to be a mixture of the proposals by Stefano,
> Ricardo and Giacomo and will use the cache key and validator idea.
> I am not quite sure about caching and content aggregation yet,
> because I didn't quite get this SAXConnector stuff. But I think we
> can solve this easily if I post the solution later this day (hopefully).

I'm looking forward to hear it :)

Giacomo

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message