cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Davanum Srinivas <d...@yahoo.com>
Subject Re: [VOTE] (was: [RT]: Merging Stream And Event Pipeline)
Date Tue, 02 Apr 2002 16:26:08 GMT
+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 <sylvain.wallez@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


Mime
View raw message