cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carsten Ziegeler" <>
Subject [C2]: Questioning the SAXConnector concept
Date Mon, 14 May 2001 07:48:27 GMT

as promised earlier here are my thoughts about the SAXConnector
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 
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.
2. Make the configuration optional, which means if I don't specify
   a SAXConnector, noone is used improving performance.
3. Add later the profiling and debugging connectors etc.

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....


Open Source Group                        sunShine - b:Integrated
Carsten Ziegeler, S&N AG, Klingenderstrasse 5, D-33100 Paderborn                          mailto: 

To unsubscribe, e-mail:
For additional commands, email:

View raw message