cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Torsten Curdt <tcu...@dff.st>
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.

+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..
--
Torsten


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message