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.
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.
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'.
The idea is to be possible for a pipeline to be 'separated' and content
injected into another pipeline, awaiting for the requestor to make
another request on another URI.
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.
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. (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)
> 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
> 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)
> <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.
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.
What do you think?
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<[EMAIL PROTECTED]> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
