You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by giacomo <gi...@apache.org> on 2001/04/09 23:42:31 UTC
Re: cvs commit: xml-cocoon/src/org/apache/cocoon/components/saxconnector
NullSAXConnector.java SAXConnector.java
On 9 Apr 2001 prussell@apache.org wrote:
> prussell 01/04/09 14:25:56
>
> Modified: src/org/apache/cocoon/components/pipeline Tag: xml-cocoon2
> NonCachingEventPipeline.java
> src/org/apache/cocoon/components/saxconnector Tag:
> xml-cocoon2 NullSAXConnector.java SAXConnector.java
> Log:
> Added component setup stage for SAXConnectors. Preliminary requirement for
> IncludeSAXConnector which will form the foundation of the content
> aggregation functionality within Cocoon2.
Paul,
Can you explain how this kind of content aggregation works together with
caching?
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 :)
Giacomo
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: AW: cvs commit: xml-cocoon/src/org/apache/cocoon/components/saxconnector NullSAXConnector.java SAXConnector.java
Posted by Giacomo Pati <gi...@apache.org>.
Quoting Carsten Ziegeler <cz...@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
AW: cvs commit: xml-cocoon/src/org/apache/cocoon/components/saxconnector NullSAXConnector.java SAXConnector.java
Posted by Carsten Ziegeler <cz...@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. How are you intending to implement
> caching? Using the cache key and validator idea, or something else?
>
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).
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: cvs commit: xml-cocoon/src/org/apache/cocoon/components/saxconnector NullSAXConnector.java SAXConnector.java
Posted by Paul Russell <pr...@apache.org>.
* 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. How are you intending to implement
caching? Using the cache key and validator idea, or something else?
Paul.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org