cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
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]
>
Gotcha!

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

  (2-3).(3-x)

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 http://myblocks.org/pdf/2.(3-x)

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                               <stefano@apache.org>
--------------------------------------------------------------------




---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message