cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From giacomo <giac...@apache.org>
Subject Re: AW: [C2]: Questioning the SAXConnector concept
Date Tue, 15 May 2001 20:06:20 GMT


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 :/

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

> 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


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


Mime
View raw message