> From: Stefano Mazzocchi [mailto:[EMAIL PROTECTED]] > So, expect my comments soon.
It's been a while, so I wanted to recap previous discussions from the archives. (No pressure, Stefano, I'm just trying to do some of the legwork :) Stefano's last word on the subject was here (http://www.mail-archive.com/cocoon-dev@xml.apache.org/msg12420.html) To summarize, Vadim proposed his Multiplexer idea as a better solution than pipe-aware selection. Stefano agreed, thought the idea more elegant, but asked for a recap of the issues, and a specific proposal from Vadim. The multiplexer came out of a larger proposal from Vadim, (I can't find it in the archive) in which serializers could be given destinations, which sparked the Sources and Drains thread. The key questions there I felt were, "should we allow a component that triggers pipelines that don't return data?" and "What kinds of piplines should be allowed?" IMO, the multiplexer idea stands on its own, without the larger proposal. As Carsten pointed out, you can achieve a non-returning pipeline by side-effect: what's the difference between a pipeline that doesn't return any events and an explicit drain? If adding explicit drains reduces architectural clarity, it should be avoided. To be honest, I haven't looked at Daniel's new selection code, but from the description, given its use of DOM and additional pipeline generation, I still think Vadim's Multiplexer proposal comes out ahead in terms of elegance and performance. Plus it has more use cases than simple pipeline dispatching. Open questions: does Schecoon and/or the recent labels discussion change any of this? Excerpted below is Vadim's idea, from (http://www.mail-archive.com/cocoon-dev@xml.apache.org/msg11409.html ) <excerpt> > I have another one, it provides different functionality but it features > similar approach. As I don't have a name for this (multiplexer?), here > is the diagram: > > - pipeline1 - > / \ > request -> A -> X - pipeline2 - X -> C -> response > \ / > - pipelineN - > > Explanation: > 1. Request goes in > 2. Pipeline is being constructed from A, X, C > 3. SAX events passed from the A to X, where they are dispatched (same as > separator) to several other pipelines > 4. SAX events passed from these events reassembled into the one SAX > stream by the same instance of X component 5. Result passed down the > original pipeline to the C 6. C spits out the response > > Don't answer "hey, you can do this with content aggregator" - it is not > true, this is a different thing. </excerpt> -- Gregory Weinger To work is not merely to produce, it is to give value to time. [[EMAIL PROTECTED]] Eugene Delacroix -------------------------------------------------------------------- --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
