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]