cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pier Fumagalli <p...@betaversion.org>
Subject Re: RFC-2396 (Was: Re: [RT] composition vs. inheritance in blocks)
Date Mon, 04 Apr 2005 16:18:28 GMT

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
>>
>> Anyhow, feel free to discuss it here...
>
> I read your rant and agree with it, it seem benefical to take 
> advantage of java.net.URI. I'm not completely happy with letting 
> relative sitemap paths be opaque and absolute be hierarchical, but I 
> don't see any better alternatives.

The thing is that the scheme specific part of the opaque URI, is 
actually a relative URI which can be resolved against an absolute 
one...

URI relative_uri = 
absolute_uri.resolve(opaque_uri.getSchemeSpecificPart());

As simple as that...

>
> Concerning:
>
>  block:super://blah.xml
>
> it is AFAICS a correct opaque URI. But we could make better use of 
> java.net.URI if we considered a hierarchial URI scheme for blocks 
> instead. From this perspective the scheme that Reinhard suggested 
> makes sense
>
>  block://portal/foo
>
> for refering to the absoute path "/foo" within the portal block,
>
>  block:/foo
>
> for refering to the absolute path "/foo" within the current block and
>
>  block:./bar
>
> for refering to the relative path "bar" relative to the current 
> (sub)sitemap within the current block and
>
>  block:super:/foo
>
> for refering to the absolute path "foo" whithin the super block of the 
> current and possibly
>
>  block:super:./bar
>
> for refering to the relative path "bar" relative to the current 
> (sub)sitemap within the super block of the current.
>
> The last three URIs are opaque and could be resolved to absolute 
> hierarchical URIs with a similar algorithm as you proposed for 
> "cocoon:./" resolution.
>
> Maybe using "//portal" as an authority is stretching the intepretation 
> to far.

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...

> Using an URIs like the ones above has the advantage that we can reuse 
> most of the definition of hierarchial URIs and the functionality in 
> java.net.URI, if we instead go for the opaque style exemplified by 
> "block:super://blah.xml" we have to define the URI parsing ourselves 
> instead.

The only problem I have with "block:super://blah.xml" is that "//" in 
an URI indicates the start of the authority part, and this is defined 
as "user@host:port", and no matter how you see it, 
"block:...anything..." _is_ a URI, and thus should follow its spec...

	Pier

>
>                                              --- o0o ---
>
> As all URI discussions tend to provoke strong feelings for Stefano, 
> it's best to say directly that this question is not important enough 
> for me to fight about ;)
>
> But anyway, whether we go for an opaque custom protocol or base the 
> block protocol on hierachial URIs we need to get into the specifics 
> for the block URI scheme to be able to implement it.
>
> WDYT?
>
> /Daniel
>
>

Mime
View raw message