> >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: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
