cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: [RT] reconsidering pipeline semantics
Date Wed, 03 Jul 2002 09:14:53 GMT
Sylvain Wallez wrote:

> Although it is ok to call named pipelines _inside_ a sitemap (that's
> just a name change for resources), I don't like it for _inter sitemap_
> calls, like can or will be the case for subsitemaps and blocks : up to
> now, the input contract of the sitemap is the environment, and pipeline
> choice is most often directed by the request URI. Does calling named
> pipelines mean you want to add a new property to the environment, just
> as the view and action we have today ?

The design should not be constrained by implementation details, Sylvain.
Try not to think about how to make it work for now.

I've showed how I perceived named pipelines not as 'functions' to call,
but as 'small internal URI spaces' (sort of small internal virtual
hosts), I think this concept is *much* more powerful than the
'resources' we have now and it's much more block-friendly.

> IMO, the called pipeline should be defined by an URI, just as what we
> already use for the "cocoon:" pseudo-protocol. This wouldn't introduce
> yet-another naming scheme and would keep the existing sitemap contract.

Yes, I do see the danger of adding another protocol for something that
is equivalent in functionality, but I have the feeling that 'pipeline:'
could slowly deprecate 'cocoon:' which IMO, would be a good thing in the
longer term.

[of course, I *DO*NOT* want to deprecated cocoon: , just to show
different and more rational ways of doing things]

The Cocoon: protocol is not block-friendly and we can't make it so
without breaking back compatibility. Also, the name is too cocoon

> Of course, we must keep today's resources as "named pipeline snippets"
> inside a single sitemap. To answer Peter's request, we can allow a
> resource to be not terminated (i.e. not contain a serializer). I even
> think the treeprocessor already handles this (needs to be verified, though).

>                               --o0o--
> The second point I'm not comfortable with is implicit overloading. I
> have the feeling the associated behaviour will be difficult to predict
> and will make the sitemap hard to read by requiring lots of "look-ahead".

Again, it's the implementation bias that leads your design judgement.

> Consider serializer overloading. The current sitemap definition says
> that a pipeline is terminated when a <map:serialize> or <map:read> is
> encountered. With the implicit overloading semantic, this rule is no
> longer valid as the calling pipeline _may_ or _may not_ define another
> serializer. And as any <map:serialize> that's present _below_ the
> <map:call> can theoretically terminate the pipeline, this means that
> knowning if the called pipeline serializer is overloaded requires
> traversal of the entire remaining part of the sitemap, even if all
> remaining serializers are enclosed in <map:match> that will never match.

Hmmm, wait, I don't get it. From an implementation point of view, I
don't see how having explicit or implicit overloading makes any

For example, what is the difference between

 <generate .../>
 <transform type="pipeline" src="/blah"/>
 <serialize .../>


 <generate .../>
 <call pipeline="blah"/>
 <serialize .../>


The pipelines are exactly the same (they could have tons of matchers and
selectors and so on) and the resulting behavior is *exactly* the same.
There are only two differences:

 - your example places a sitemap behavior inside a sitemap component.
This appears to me an evident example of the use of the
overcomponentization anti-pattern.

 - you can't reuse the 'blah' pipeline in another location. So it is
possible that you call a pipeline fragment which is wrongly terminated.
With implicit overloading, the pipeline is always correctly terminated.

Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<>                             Friedrich Nietzsche

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

View raw message