> 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.
>
> Waiting for comments...
Tell me if this is different from what you're talking about: a
Transformer/Generator pair that acts like a combination of (modified)
FragmentExtractor and CInclude.
Say we have a MultiplexingTransformer [MT] in a pipeline like this:
Request --> G -> T -> MT -> S --> Response
MultiplexingTransformer calls 1-n pipleines via the cocoon:/ protocol.
The MultiplexingTransformer byte-compiles all the SAX events within a
given element, like this:
<mx:dispatch src="cocoon:/otheruri"
xmlns:mx="http://multiplexer";>
. . . xml elements . . .
</mx:dispatch>
And forwards the XMLFragment in a request attribute.
A MultiplexingGenerator [MG], at the head of each of the 1-n pipelines
retrieves and serialzes the XMLFragment.
Request --> MG -> T -> S --> Response
This is very similar to something I'm currently working on. If other
people would find it useful, I will generalize this and offer it up.
Or did you have some other pipeline component magic in mind? :)
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
