cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vadim Gritsenko" <vadim.gritse...@verizon.net>
Subject RE: [RT] Cocoon Symmetry (short :)
Date Sun, 10 Feb 2002 17:28:54 GMT
> From: Stefano Mazzocchi [mailto:stefano@apache.org]

Hi Stefano,
 
> Vadim Gritsenko wrote:
> >
> > Hi all,
> >
> > Preamble: I do remember we had talks about inward flows, etc... Then
> > somebody (sorry, already forgot who it was) wrote about transformer
> > which writes file as a side effect... Then Kinga proposes to add
> > handlers reacting on input stream/documents... And recently I have
got
> > an idea that it should be quite an elegant way to handle all this if
> > Cocoon is designed symmetrically: whatever abstractions we have to
> > handle outgoing flow, let apply to the in-flow.
> 
> Let me start saying that I consider 'simmetry-driven design' the
source
> of all FS.

I could guess this ;)


> So, my FS alarms will be tuned to 'sensible' as we go along.
> 
> > First of all, we already (almost) have symmetry in pipelines:
generators
> > are symmetrical to serializers. Generators are able to produce XML
> > content out of almost anything we can think of: physical file, HTTP
> > resource, SQL database, XMLDB database, incoming request, etc.
> > Unfortunately, serializers are somewhat limited comparing to the
> > generators: the only out option we have is output stream. Let's
expand
> > this to the other sources as well. Then we can have, say, file
> > serializer. Coupled with the ability of Sources to handle input
streams,
> > one can save XML stream into file, XMLDB, and other sources were
> > protocol handler exists.
> 
> This asymmetric limitation is intentional and due to the architecture
of
> the web: the response goes back to the requestor. Always.

I'm not trying to change this: pipeline must have serializer writing to
the Response output stream.


> In SMTP, for example, this is different. The above is the main reason
> why our (Pier's and mine) proposal for the Mailet API addition to the
> Servlet Framework was rejected: we should have abstracted the concept
of
> 'where does the response goes' that is now implicitly hardwire back to
> the requestor.
> 
> So, I perfectly see your point since I already hit that wall once.
> 
> > Second. Now Cocoon perfectly handles aggregation, both on sitemap
level
> > and using aggregated transformers. But what we have opposite to the
> > aggregation? Nothing. Let's add separation notion: result will be
> > several SAX streams. Every stream will have a destination pipeline.
This
> > pipeline will be retrieved by "separator", and generator of the
pipeline
> > will be replaced by the "separator" which will feed SAX events into
this
> > pipeline. As you see, it is same mechanism aggregator employs but
> > reversed.
> 
> This is admittedly a cool concept but only if designed to replace
> functionality implemented by 'fragment extractors'.

I would say: if designed so 'fragment extractors' is one of the
applications of this concept.


> The idea is to be possible for a pipeline to be 'separated' and
content
> injected into another pipeline,

Yes, that's an idea I'm trying to propose. 


> awaiting for the requestor to make
> another request on another URI.

And this is just one of possible usages of the idea.


> This would allow an *easy* way to factor out and rasterize, say,
MathML
> namespaces into included GIFs.
> 
> But yes, I think your 'separator' abstraction might be powerful enough
> to allow this.

Agree.


> The only problem I see is that if we go down this path, we have to
> explicitly indicate the 'destination' of the request, since this is
not
> a property of the serializer. 

It's not a property of a *serializer*, but this is a property serializer
is *given* by sitemap. Some examples:

<!-- default: response out stream -->
<map:serialize type="jpg" />

<!-- ugly, but straightforward -->
<map:serialize type="jpg" src="C:/Temp/out.pdf"/>

<map:serialize type="jpg" src="xmldb:xindice:/docs/{1}"/>

<!-- analogue to the fragment extractor -->
<map:serialize type="jpg" src="session:{prefix}-jpg"/> 


> (ie, I might use the PDFSerializer both to
> send back the serializer to the client or to send an email to somebody
> with it. It's not the serializer's concern, but it's the sitemap's
> concern to attach the right outputStream to the serializer)

Sitemap concern is to specify Source (or Resource), which will provide
outputStream.


> > Third. To top all this, symmetrical component is to be developed to
the
> > X/C Include transformers. As "separator", it will extract parts of
the
> > stream and send them to the other pipelines.
> 
> Hmmm, what about X/C Fragment? that would do parallel with
> 
>  aggregation <----> separation
>  inclusion  <----> fragmentation

Yes - if it is just naming convention. I agree to any name.


> > At last, let's consider an example. Let it be some request from the
user
> > to perform modification of the XML resource stored in the file (poor
> > man's CMS ;)
> >
> > <!-- inflow internal -->
> > <map:match pattern="get-data">
> >   <map:generate src="data.xml"/>
> >   <map:serialize type="/dev/null"/>
> > </map:match>
> 
> Hmmm, the need of dummy components shows that we have some problems
with
> the sitemap semantics (see below)

It has some positive sides though: (enforced) presence of serializer in
the today's out-flow pipelines allows easy debugging: you can invoke
them manually (till access is disabled by internal-only=true)


> > <map:match pattern="get-mods">
> >   <map:generate type="request"/>
> >   <map:transform src="request2data-mods.xsl"/>
> >   <map:serialize type="/dev/null"/>
> > </map:match>
> >
> > <!-- main -->
> > <map:match src="update">
> > <map:act type="validate-user-input">
> >   <map:aggregate>
> >     <map:part src="get-mods" element="mods"/>
> >     <map:part src="get-data" element="data"/>
> >   </map:aggregate>
> >   <map:transform src="apply-mods--return-data-and-result.xsl"/>
> >   <map:transform src="add-index-update.xsl"/>
> >   <map:transform src="add-news-page-update.xsl"/>
> >   <map:separate>
> >     <map:part src="put-data" element="data"/>
> >     <map:part src="update-index" element="index-update"/>
> >     <map:part src="update-news" element="index-update"/>
> >     <map:part src="update-result" element="result"/>
> >   </map:separate>
> > </map:act>
> > </map:match>
> >
> > <!-- outflow internal -->
> > <map:match pattern="put-data">
> >   <map:generate type="/dev/null"/>
> >   <map:serialize type="file" src="data.xml"/>
> > </map:match>
> >
> > <map:match pattern="update-index">
> >   <map:generate type="/dev/null"/>
> >   <map:transform type="lucene"/>
> >   <map:serialize type="/dev/null"/>
> > </map:match>
> >
> > <map:match pattern="update-news">
> >   <!-- ... -->
> > </map:match>
> >
> > <map:match pattern="result">
> >   <map:generate type="/dev/null"/>
> >   <map:transform type="result2html"/>
> >   <map:serialize type="html"/>
> > </map:match>
> >
> > PS: /dev/null: Currently, aggregator ignores serializer. That's to
show
> > that this is the dummy serializer.
> 
> Ok, I think you are suggesting something good but I see a few concepts
> that we must think about more:
> 
> 1) serializers should have no notion of where their output goes. this
is
> a property of the pipeline.

Agree. If this means that output should be specified via src="". But
type of serializer should mean type of the output it producing, not
destination of this output.

 
> 2) there are three types of pipeline:
> 
>  - complete: G -> T* -> S
>  - generating: G -> T*
>  - serializing: T* -> S
> 
> interesting enough, for the in-out flow, internal-only pipelines are
> 'generating pipelines' and views are 'serializing pipelines'.
> 
> So, we already have this semantic, we just have to expand it a little.

Ahem.
1. Semantically, views are "exit points" for the other pipelines. They
are not supposed to be used standalone, but to generate different
*views* of the same resource.
2. Technically, views do not have a URI to identify them - which is
required to resolve a Source (Resource in the future).
3. Pragmatically, what would be the behavior of the separator if I
request view, using cocoon-view=links? Does it mean we have to introduce
views of views (recursion)?

Let not spoil view concept, it goes in totally different direction. And
you will be able to use views *with* the concept I'm proposing to
generate, ahem, different views of the same complex pipeline with the
aggregators/separators.

Makes sense?

Vadim
 
> What do you think?
> 
> --
> Stefano Mazzocchi      One must still have chaos in oneself to be
>                           able to give birth to a dancing star.
> <stefano@apache.org>                             Friedrich Nietzsche
> --------------------------------------------------------------------


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message