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
overhead)
 - assemble pipelines for maximum information (means lots of debug/trace
overhead)

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.
<[EMAIL PROTECTED]>                             Friedrich Nietzsche
--------------------------------------------------------------------


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Reply via email to