Re: [RT] Using pipeline as sitemap components (long)

[Sylvain Wallez]

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: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]