> -----Original Message----- > From: Vadim Gritsenko [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, February 20, 2002 4:28 PM > To: [EMAIL PROTECTED] > Subject: RE: is cocoon symmetry a holy grail? > > > 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?
That's right, byte-compiled into an XMLFragment. > > 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. Granted. > 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). Where do we stand on this proposal, though? Looking back, it seems there was some apprehension about the changes to the sitemap semantics, such as having "null" generators or serializer destinations. Starting with a Generator/Transformer pair like I suggested would introduce the separation concept, without altering the sitemap. It eliminates the need for an "empty" generator in a pipeline. If usage and interest is sufficient (or performance insufficient), that might be an indication that it belongs in the sitemap as well. The serializer destination concept is beyond my expertise, so I can't comment on it other than to say it seemed controversial. As far as names go, I prefer SeparatorTransformer or PipelineDispatcherTransformer. I don't like X/CExclude because it sounds like the elements are being discarded. Greg --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
