cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Torsten Curdt <>
Subject Re: [VOTE] (was: [RT]: Merging Stream And Event Pipeline)
Date Wed, 03 Apr 2002 10:13:51 GMT
> >Hi,
> >
> >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.
> >
> +1.


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

+1 ..I have never understood why they are not a SitemapModelComponent

> >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 ;)

a big +1

> >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 ;)

that's how I see it too..

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

View raw message