cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject [RT] The block protocol (was: RFC-2396)
Date Mon, 04 Apr 2005 21:28:47 GMT
Daniel Fagerstrom wrote:
> Pier Fumagalli wrote:
>> On 4 Apr 2005, at 16:26, Daniel Fagerstrom wrote:
>>> Pier Fumagalli wrote:
>>>> On 31 Mar 2005, at 01:26, Stefano Mazzocchi wrote:
>>>>>  block:super://blah.xml
>>>> A very simple remark, I don't want to criticise...
>>>> I'm already slightly "upset" about the "cocoon://" protocol, as it 
>>>> does not follow the URI RFC properly, I'd like to address the 
>>>> problem as early as possible...
>>>> I wrote a small "rant" while on the plane, just to explain my 
>>>> reasoning, with a couple of code examples, as it's (I don't think) 
>>>> mailing-list material, I've stored it on my WIKI...


>> Exactly... That's why I'm thinking that the URI should be this:
>> block:portal:/foo
>> block is an opaque URI, whose scheme specific part _is_ a valid URI by 
>> itself.
>> portal:/foo is a valid URI, but if (for example) you think about other 
>> cases, this URI could be
>> block:xmlrpc://www.myrpcserver.dom/entry/point
>> block: opaque URI
>> xmlrpc: valid URI whose scheme specific part (whether it's opaque, 
>> absolute, relative, blah) is only known by the "xmlrpc" handler...
>> block:portal:/foo
>> What's "/foo"? Only the portal block knows it...


I have thougth a litle bit more about the block URI and the architecture 
around it so I do a new trial.

                             --- o0o ---

The main involved components are the BlocksManager that in turn has 
access to one BlockManager for each block.

Block local access

Each BlockManager has its own SourceResolver and especially it can have 
its own implementation of the block protocol which is registred with the 
scheme "block:".

An absolute URI relative to the root sitemap of the block looks like:


and is a hierarchical URI. It is invoked by first trying "foo/bar" in 
the current block's root sitemap and if that fails 
"block:super:/foo/bar" is invoked. More about "block:super:" later. To 
make this work I would assume that error handling must work a little bit 
different in blocks so that a sitemap can fail without emmiting any 
error messages immediatly.

In the case when a block A has invoked an URI in its super block B, to 
achieve polymorphism, all block protocoll resolution in B must be done 
by first asking A's block resolver before trying its own.

A relative URI in a sub sitemap "/foo" from the block's root sitemap,


(an opaque URI) is resolved to


using the same method as Pier used for the cocoon protocol in his Wiki.

Inter block access

An URI to another block "skin" e.g. looks like:


the BlockManager resolves it by looking up "skin" in the wiring info for 
the block ( and find the mapping:

   skin ->

in the connection section, where 
"" uniquely identifies the 
specific skin implementation that has been choosen at deploy time.

Is the URI unique enough? What if I want several variants of the skin 
that has different deployment parameters and implementations of theire 

Interesting enough, IIUC, blocks are only accessible through the block 
protocol from other blocks, as the short name, "skin" e.g., only exists 
in the block wiring info. Are we going to consider the main sitemap part 
of a block as well to be able to access blocks from it?

Next the block manager asks the blocks manager for the URI, this could 
be done through a "blocks:" protocol that is connected to the blocks 
manager. The uri "block:skin:/foo/bar" could be resolved to e.g.:


Besides that it looks awfull I would doubt that it even is synatactic 
correct as an opaque URI. I only wrote it down to provoke you to find 
something better ;)

Next the blocks manager looks up the block manager identified by 
"" and send the URI:


to it, which will be resolved by the skin blocks internal implementation 
of the block protocol.


is resolved in the same way as an ordinary external block URI. To make 
this possible the role of being a super block must be identifiable among 
the connections in the wiring info. Maybe by reserving the name "super" 
for this case.



View raw message