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 Wed, 16 May 2001 10:05:01 GMT
> Giacomo Pati wrote:
>
>
> On Tue, 15 May 2001, Carsten Ziegeler wrote:
>
> > > 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...
>
> Well, the URLFactory returns an URL. What you are looking for is
> something you can put a ContentHandler into it, right? How would you
> distinguish between a normal "URL" which represents a Stream you can
> read from and a "Cocoon URL" which is obviously looking for a
> ContentHandler to spit the SAX event to.
>
> Would you always pass in a ContentHandler when you request a URL from
> the URLFactory and catch exception if it doesn't support ContentHandler?
> Or would you always check if the URL can eventually handle
> ContentHandlers? I still have not found a clever solution to the
> problem and it seems nobody else as well :/
>
OK, you are right. This is really a problem. The simple (slow) solution
is of course when the URL handler returns always an input stream which
is then reparsed.
But ok, this is not a clever solution. I fear that there is no clever
solution for this. Hm, I will think about it.

> > On the other hand would it really hurt if all components have access
> > to the sitemap?
>
> Hmm.. would you support giving the power of the sitemap to component and
> XSP writers and can you support all the question that would arise when
> using it in ways we never thought of using it?
>
Yupp, that is really a pointer I never had thought of. But, again, you are
right. We really don't want that. So it is no choice!

> > 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?
>
> Yes, explicitly knowing and defining what I want to use is my
> intension :)
>
> Giacomo
>

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