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. 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. 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. 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"/> <serialize> Ok, ignore this last comment - I only had to show how usefull web services can be - even for Cocoon :) Carsten --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
