+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]
