cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: SAXConnector use cases (was Re: [VOTE]: The future of the SAXConnector)
Date Sat, 29 Jun 2002 10:55:13 GMT
Sylvain Wallez wrote:

> So finally, I'm in favor of removing SAXConnector _now_, but be prepared
> to see something appear in the future that will be really orthogonal to
> pipelines and will hopefully improve the so-called "user experience"
> when an error occurs !

I see your point and I agree, but I would like to add a little warning
to what you're trying to achieve.

Cocoon suffers from overavalonization, the anti-pattern of usign Avalon
too much, even when a more simple solution would make more sense.

This is the best example: since it's possible to abstract the SAX
connections, then we make them components and allow users to plugin
their own.

Sure it's powerful, but it's *too* powerful. In order to plug them in
and write goo ones, they have to know *all* the cocoon internals very
well. Since not even us were able to create more than a few non-obvious
examples of those components, this is clearly labelling itself as FS.

Rather, you propose a serious and important issue with
'development-oriented pipeline assembly', but this doesn't mean that the
user has to know what SAX connector is used for this.

It would be enough to have a cocoon configuration trigger that says:

 - assemble pipelines for maximum performance (means no debug/trace
 - assemble pipelines for maximum information (means lots of debug/trace

So the uses doesn't have to *know* how to do it, but the functionality
you wanted is there without the need for overcomponentization which
smells like FS too much.

How does that sound?

Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<>                             Friedrich Nietzsche

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

View raw message