cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: [design] Cocoon Blocks 1.1
Date Sun, 03 Nov 2002 13:56:17 GMT
Sylvain Wallez wrote:

> The contract of a block should be services identified by their URI, 
> and not files at well-known locations (even if these 'files' are in 
> fact produced by a pipeline).
> <snip/>
> By considering blocks as pipeline services, we really achieve true
> polymorphism for blocks, because we totally abstract the way their
> contracts are implemented.
> [note that all the above isn't in fact block-specific and can be made
> today inside a single sitemap]

What can I say: I agree!

> After this we had a long conversation about the semantics to be used 
> to identify which part of a pipeline we want the caller to use, which
> unfortunately fell flat because I wasn't able to make you understand 
> my thoughts. I'd like someday to have the luck Carsten had recently to 
> meet you for real. Too bad the GetTogether is the same week as the 
> ApacheCon :-(

Yeah :/ well, you know, you were next on my list anyway :)

Ah, BTW, I'm going to be travelling a lot in the next month or so, I'll 
post a schedule so that if anybody is around and want to have a beer and 
talk geek, I'm game.

> Anyway, let's forget for now these syntactic problems. The important
> thing above is that a block should provide services by means of 
> pipeline URIs and not resources.

Good, I like it. Care to edit the version 1.2 of that document to show 
us what you mean also syntactically? I think that would help a lot.

> > The best solution is to allow my block to explicitly "extend" that
> > block and inherits the resources that it doesn't contain.
> Side note : we must not forget to allow a block to call
> services/resources of its parent block (like a "super" call in Java).

How do you envision this to happen? Can you come up with a real need for 
such a thing? Just checking you are designing by parallel here. In fact, 
I added inheritance after I noticed that one of my customers I did 
consulting for had a problem that could be solved wonderfully with block 
inheritance (mostly, it was block personalization for different customers).

Also, how do you make this happening? something like

  <map:call resource="block:parent://whatever/service"/>

would that be enough? could that be harmful or provide security concerns?

> > TODO
> > ----
> >
> >  1) blocks should allow to depend on 'ranges' of behavior versions.
> > Let's try to come up with a way to describe those ranges effectively.
> IIRC, there's something in Avalon to handle this.

Hmmm, not sure.

Here is a possible syntax for versioning ranges of block behaviors:

  1.3 -> matches version 1.3 only
  1.x -> matches all minor versions of the first major version
  1.(3-8) -> matches from version 1.3 to 1.8 included
  1.(3-x) -> matches all versions higher than 1.3 and lower than 2.0

which can also be applied to block versions

  1.3.340 -> matches bugfix 130 of minor version 3 and major version 1
  1.3.(48-x) -> matches from bugfix 48 on

NOTE: multiple ranges are semantically meaningless, for example


since there is no semantic correlation between the same minor versions 
if done on different major generations. Or, at least, there should be none.

So, if you say:

  this block implements

you are infact indicating that your block implements all 2.x versions of 
the behavior starting from 2.3 and up to 3.0 excluded.

> Ok. I hope this time this notion of "pipeline services" will go 
> further and that we will solve the misunderstanding we had 4 months ago...

Yeah, I think it will. Last time you threw in the syntactic concern 
hoping that others understood the semantic concern underneath it, but 
this time is definately clearer :)

Stefano Mazzocchi                               <>

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

View raw message