Re: [VOTE] (was: [RT]: Merging Stream And Event Pipeline)

[Ovidiu Predescu <ov...@cup.hp.com>]

Three +1 from me too.

Please post the new interface for the new pipeline so I can think of
how to modify the code in Schecoon accordingly.

Thanks,
Ovidiu

On Tue, 2 Apr 2002 08:26:08 -0800 (PST), Davanum Srinivas <di...@yahoo.com> wrote:

> +1 for (merging the stream and the event pipeline).
> +1 for (Allow a Serializer to be a SitemapModelComponent. ***I REALLY NEED THIS***)
> +1 for (Configurable pipelines)
> 
> Thanks,
> dims
> 
> --- Sylvain Wallez <sy...@anyware-tech.com> wrote:
> > Carsten Ziegeler wrote:
> > 
> > >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 !
> > 
> > >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 !
> > 
> > >Cheers
> > >Carsten
> > >
> > 
> > Sylvain
> > 
> > -- 
> > Sylvain Wallez
> >   Anyware Technologies                  Apache Cocoon
> >   http://www.anyware-tech.com           mailto:sylvain@apache.org
> > 
> > 
> > 
> > 
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> > For additional commands, email: cocoon-dev-help@xml.apache.org
> > 
> 
> 
> =====
> Davanum Srinivas - http://xml.apache.org/~dims/
> 
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Tax Center - online filing with TurboTax
> http://http://taxes.yahoo.com/
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
> 
> 

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