> From: Greg Weinger [mailto:[EMAIL PROTECTED]] > > > 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,
You mean it buffers all SAX events under specified 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? :) Yep, I'm thinking about similar concept, but bit different implementation. Key difference would be that no buffering is required. SAX elements will be directly forwarded to chosen pipeline, and result of this pipeline immediately streamed down the multiplexer's pipeline. This should work better on large documents: lesser memory usage and better perceived performance can be achieved. Another difference is in the way how to specify which elements should be multiplexed. These elements can be specified in the sitemap (similar to map:aggregate/map:part syntax) or in the document itself (similar to CInclude's include element). Vadim --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
