This document defines this concept of "pipeline service", which, as we will see, consists in using pipelines as sitemap components (generator, transformer and serializer). It is separated from the blocks design document since pipeline services can be used without blocks, even if they will be mostly useful in that context.
Interesting read, Sylvain (BTW: you should have told us that some guys from your company were at Comdex :-) We met them yesterday at the Cocoon BOF and I would have been most interested to meet them there... anyway, kudos for the great job of putting Cocoon in such a small device, definitely impressing).
I have a some problems, though, with the whole concept. First of all I hear FS bells all around, but I still have to focus more on the topic. The secon problem is about extending pipeline syntax in such a radical way: I think that this deserves a lot of thoughts about what might come out from this change.
The third and last one has to do with the specific syntax. What you are labeling as a type="pipeline" attribute is actually the result of a matcher (i.e. a "<map:match src="whatever">" tag). This might really be confusing. But then again I can't think of a name that might really make sense: using <map:transform match="whatever"> is even worse, so I don't really see a solution here.
What I see here is actually expressing in an explicit way the fact that when you are calling a resource via the cocoon protocol the serializer is infact ignored and the two pipelines are infact somehow "merged"... but I need to have more use scenarios where extending this might turn out useful without falling into FS. Can you shed some more light on that, with special regard to the whole block concept?
Ciao,
--
Gianugo Rabellino
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
