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...
http://www.ietf.org/rfc/rfc2396.txt
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...
http://www.betaversion.org/~pier/wiki/display/pier/Cocoon+and+URIs
<snip/>
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...
<snip/>
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:
block:/foo/bar
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,
block:./bar
(an opaque URI) is resolved to
block:/foo/bar
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:
block:skin:/foo/bar
the BlockManager resolves it by looking up "skin" in the wiring info for the block (http://wiki.apache.org/cocoon/BlocksWiring) and find the mapping:
skin -> http://mycompany.com/skins/corporate/34.3.345
in the connection section, where "http://mycompany.com/skins/corporate/34.3.345"; uniquely identifies the specific skin implementation that has been choosen at deploy time.
<comment>
Is the URI unique enough? What if I want several variants of the skin that has different deployment parameters and implementations of theire connections.
</comment>
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.:
blocks:{http://mycompany.com/skins/corporate/34.3.345}:/foo/barBesides 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 "http://mycompany.com/skins/corporate/34.3.345"; and send the URI:
block:/foo/bar
to it, which will be resolved by the skin blocks internal implementation of the block protocol.
block:super:/foo/bar
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.
WDYT?
/Daniel
