cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylvain.wal...@anyware-tech.com>
Subject Re: [RT] Using pipeline as sitemap components (long)
Date Sun, 24 Nov 2002 13:09:55 GMT
Carsten Ziegeler wrote:

>I'm sorry - I really value the effort, Sylvain has put into 
>writing this RT, but I'm currently against forcing this new concept
>of "pipeline services" into the existing features by adding
>some special components with a very special behaviour.
>
>The cocoon protocol is a *protocol*, so it works like any other
>protocol (http, ftp etc). A protocol is usually not forced
>to deliver a strict content type (like xml). If you
>see http://something/here you don't know what content and in
>which format this is delivered.
>And actually the same is true for the cocoon: protocol. You
>can have a 
><map:match pattern="test">
>   <map:read src="bla"/>
></map:match>
>and use cocoon:/test returning the byte stream of the reader.
>No XML in here, no SAX events etc.
>The other way also works:
><map:match pattern="test"
>    <map:read src="cocoon:/some-pipeline"/>
></map:match>
>
>Let's not discuss if these examples are very usefull. But these
>are examples of usual protocol usage and they show the way you
>usually handle protocols.
>
>It is correct, that internally in most cases the serializer
>of a pipeline is ignored, when the cocoon protocol is used.
>But this is only because of performance.
>
>You can totally confuse new cocoon users by telling them
>that the serializer does not have to be the xml serializer.
>Because they don't know the internal things of Cocoon which
>we know. And it's not obvious for them.
>

I don't agree with the above : the first thing that a Cocoon user has to 
know are the concepts of generator, transformer and serializer. And all 
documents explaining these concepts explain the usage of SAX events (or 
at least XML documents) to communicate between components and the fact 
that the serializer translates SAX events to a byte stream.

The concept of SAX-event pipeline is *the* fundamental concept of 
Cocoon. A such, a user not knowing this concept will understand about 
nothing to what Cocoon is and what it can do.

But let's not argue about this, which isn't the real problem here.

>So, defining a service with a generator and a serializer where
>both are ignored is absolutely not intuitiv and will scare 
>many.
>And I can already hear the complains :"What? This should be the
>new great concept and I always have to specify a generator
>and serializer and then they are not used. Now, that's simple."
>
>Let's be honest - do you know any framework etc. where you
>have to specify things which are not used to define this
>service? It's like implementing a method where you have to
>add some statement at the beginning and at the end and then
>later on they are ignored.
>

Mmmh... what about languages like Eiffel where each method can have 
preconditions and postconditions (or the new "assert" in JDK 1.4) ? 
Depending on the runtime environment, these blocks may or may not be called.

>I think we should not mix things: the concept we want and
>how to implement it. We should first focus on what we want
>and than see how it fits into our architecture. Let's not
>talk at this stage about SAX events etc.
>
>So, my perception is that we want to have services that
>can be used as a generator, as a transformer and as a
>serializer.
>
>The first question is: how can I call these services
>and the second one is how can one define a service?
>
>We saw some different examples on this and I personally like
>a new syntax best to call a service instead of defining
>a special component (generator, transformer, serializer).
>As Stefano mentioned, we did this for content aggregation
>as well.
>  
>

Content aggregation is a different thing, since we want to *merge* 
different sources, which isn't possible with a language (the sitemap) 
that defines a linear pipeline.

Note also that Cocoon provides another way of aggregating content 
through the X/Cinclude transformers, which are nothing but regular 
sitemap components.

>And I think if we have a special syntax for calling a service
>it's nearly natural to have a special concept for defining
>the service as well.
>

Yep. But once again, there is no new concept on the caller part. I admit 
the syntax is somewhat stretched on the callee and that we may want a 
particular syntax there, but certainly not on the caller part.

So what if we introduce some new statements to define incomplete 
pipelines to be used as pipeline services ? For example, a serialization 
service could be defined using :

<map:begin-service/>
<map:transform src="xdoc2fo.xsl"/>
<map:serialize type="fo2pdf"/>

and a transformation service could be defined using :

<map:begin-service/>
<map:transform src="foo.xsl"/>
<map:end-service/>

That is <map:begin-service> replaces a <map:generator> that would be 
ignored and has to be used for transformation or serialization services. 
Similarily, <map:end-service> replaces a <map:serialize> that would be 
ignored and has to be used for generation or transformation services.

>And one interesting thought: I could imagine that as soon
>as people can call a cocoon pipeline as a transformation
>service they will want to call a web services doing the same
>as well, so something like this comes into mind:
><generate src="hallo.xml"/>
><call-pipeline src="http://server/transformation"/>
><serialize>
>

Why should a remote web service be called with a "call-pipeline", which 
is a Cocoon concept ? Here again, we just want transformation. So this 
can be written :

<generate src="hallo.xml"/>
<transform type="soap" src="http://server/transformation"/>
<serialize/>

>Ok, ignore this last comment - I only had to show how usefull
>web services can be - even for Cocoon :)
>

This comment is really useful to show that there's no need for a new 
<call-pipeline> ;-)

Sylvain

-- 
Sylvain Wallez                                  Anyware Technologies
http://www.apache.org/~sylvain           http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }



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


Mime
View raw message