cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carsten Ziegeler" <>
Subject RE: [RT] Using pipeline as sitemap components (long)
Date Sun, 24 Nov 2002 11:00:58 GMT
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"/>
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"/>

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.

So, defining a service with a generator and a serializer where
both are ignored is absolutely not intuitiv and will scare 
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.

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

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.

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.

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"/>

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


To unsubscribe, e-mail:
For additional commands, email:

View raw message