+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)
Also I think this consolidation is a good base for future pipeline additions, like adaptive caching or better handling of error streams. However -> kool Carsten. ~Gerhard "Sorry, but my karma just ran over your dogma." >-----Original Message----- >From: Davanum Srinivas [mailto:[EMAIL PROTECTED]] >Sent: Tuesday, April 02, 2002 6:26 PM >To: [EMAIL PROTECTED] >Subject: Re: [VOTE] (was: [RT]: Merging Stream And Event Pipeline) > > >+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 <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED] >> >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, email: [EMAIL PROTECTED] >> > > >===== >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: [EMAIL PROTECTED] >For additional commands, email: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
