cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Greg Weinger" <gwein...@itmedicine.net>
Subject RE: is cocoon symmetry a holy grail?
Date Thu, 21 Feb 2002 01:50:03 GMT
> -----Original Message-----
> From: Vadim Gritsenko [mailto:vadim.gritsenko@verizon.net]
> Sent: Wednesday, February 20, 2002 4:28 PM
> To: cocoon-dev@xml.apache.org
> Subject: RE: is cocoon symmetry a holy grail?
> 
> > From: Greg Weinger [mailto:gweinger@itmedicine.net]
> >
> > > 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: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message