cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carsten Ziegeler" <cziege...@sundn.de>
Subject AW: [C2]: Questioning the SAXConnector concept
Date Tue, 15 May 2001 08:58:39 GMT
> Giacomo Pati wrote:
> 
> On Mon, May 14, 2001 at 09:48:27AM +0200, Carsten Ziegeler wrote:
> > Hi,
> > 
> > as promised earlier here are my thoughts about the SAXConnector
> > architecture. 
> > Too keep it short, there are some disadvantages with this concept:
> > 
> > 1. The caching algorithm can not detect any changes to included
> >    documents. If you use the XInclude or CInclude connector
> >    and only the included content changes the cache gets never 
> >    invalidated.
> > 2. It is not possible to use more than one SAXConnector. If I 
> >    want to use a feature of more than one SAXConnector it is 
> >    simply not possible.
> > 3. Changing the type of SAXConnector might change responses. 
> > 
> > Don't get me wrong, I like the SAXConnector concept for profiling,
> > debugging etc. But not for content aggregation. If I want to 
> > write a debugging connector and want to use it, I can't use one
> > of the Include connectors.
> > Another point might be performance. I assume that 95% of the
> > pipelines you define do not use the transparent content aggregation.
> > But between each pipeline components is a SAXConnector which doubles
> > the (avalon) components looked up for each request.
> > 
> > So my proposal for the first beta is:
> > 1. Make transformers from the X/CIncludeConnector.
> 
> +0
> 
> > 2. Make the configuration optional, which means if I don't specify
> >    a SAXConnector, noone is used improving performance.
> 
> +1
> 
> > 3. Add later the profiling and debugging connectors etc.
> 
> +1
> 
> > I know that this issue has discussed several times, but as
> > far as I remember there was no consense right now on this topic.
> > If you all say: NO, we want the SAXConnectors as they are right now,
> > ok no problem and I will shut up with this and we can make the
> > beta even faster....
> 
> The problem with the normal Transformers are that they cannot 
> include Cocoon specific resources because they don't get access to 
> the sitemap object in charge. There are several ways to achieve that 
> but all of them will open up the sitemap object to *all* components. 
> 
Ok, you are right this is a problem. Could we solve this in any way
by using the URLFactory. We could perhaps make a URL handler for the
cocoon:// url which has access to the sitemap. And this access is
restricted to this handler. I don't know how to do this. But perhaps
there might be a good way...
On the other hand would it really hurt if all components have access
to the sitemap?

Looking at your votes, it seems to me that we should use the transformer
way instead of the sax connector architecture (apart from the problem
above). Am I right?

Carsten 

Open Source Group                        sunShine - b:Integrated
================================================================
Carsten Ziegeler, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
www.sundn.de                          mailto: cziegeler@sundn.de 
================================================================



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


Mime
View raw message