cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Greg Weinger" <>
Subject [SUMMARY] Viva la Multiplexer! (was: [Contribution] Pipe-aware selection)
Date Thu, 04 Apr 2002 20:27:28 GMT
> From: Stefano Mazzocchi [] 
> 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
( 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
( )


> I have another one, it provides different functionality but it
> 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
> 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
> true, this is a different thing.


Gregory Weinger                  To work is not merely to produce,
                                      it is to give value to time.  
[]                        Eugene Delacroix

To unsubscribe, e-mail:
For additional commands, email:

View raw message