cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject [VOTE] (was: [RT]: Merging Stream And Event Pipeline)
Date Tue, 02 Apr 2002 16:13:30 GMT
Carsten Ziegeler wrote:

>just a short and simple RT for today:
>What do you all think about merging the stream and the event pipeline
>into one single interface/object?
>This would make the system less complex and reduce lookups per request
>as well.


I'd like also we take a formal decision about allowing a Serializer to 
be a SitemapModelComponent. This comes regularly on the table, and there 
have been several uses cases showing the need for it, mainly to access 
the SourceResolver. And I've got a new use case : I'm currently adding 
source resolving capabilities to SVGSerializer to allow bitmaps to be 
read using the "blob" SourceFactory. For this, the serializer *needs* 
the SourceResolver and thus I have a patched version of StreamPipeline 
that handles this. I also know that other people are using similar hacks 
(Dims once sent this hack as an aswer to one of your questions).

So : do we allow a Serializer to be a SitemapModelComponent ?
+1 from me !

>The splitting into those two objects was done to help implementing the
>cocoon: protocol. But AFAIK everywhere always those two objects are
>used in combination, even in the SitemapSource class implementing the
>cocoon: protocol.

Be careful : we must keep an "XML exit point" on the new Pipeline, since 
toSAX() on a SitemapSource outputs the XML just before the serializer, 
in order to avoid parsing of the output of the serializer. For this, we 
could either allow the serializer to be set more than once, or add a new 
process(environment, XMLConsumer) method.

>And as we want to make configurable pipelines for the next release,
>this would be easier to handle as well.

+1 for configurable pipelines. I'm currently struggling with a pipeline 
that I would like to be not cacheable but that is because other 
pipelines have to be cacheable ;)

>I know this is an incompatible change, but I think this wouldn't hurt
>anybody as I never heart of someone really implementing these interfaces.

These are very internal components, and the super-power-users that 
tweaked with them should be able to update their hacks ;)

>So, comments etc are welcome!

... and votes !



Sylvain Wallez
  Anyware Technologies                  Apache Cocoon 

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

View raw message