cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: cocoon:// design bug?
Date Sun, 18 May 2003 01:50:01 GMT
on 5/17/03 12:20 PM Torsten Knodt wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
>>I did some spec-reading [1], and although the most general URI syntax
>>doesn't specify the format of what follows the scheme (cocoon:),
>>resolving relative URI's is only supported for those that use the
>>hierarchical path syntax.
> 
> Yes. And thats what cocoon should be. It should work like file:.
> 
> 
>>So in short, there's no problem as long as we assume we'll never have to
>>resolve relative URL's against cocoon: base URL's. But I'd rather avoid
>>posing this restriction.
>>[1] http://www.ietf.org/rfc/rfc2396.txt
> 
> Bad. Very Bad. Assume you do <map:part src="cocoon:/blablalbla">. Now I want 
> to resolve the URI's in this document against the given URI and then 
> relativize against the URI of my current pipeline.
> 
> 
>>I think we'd have a hard time convincing everyone here to change this
>>syntax now. And it would break backwards compatibility with Cocoon 2.0.
> 
> I would suggest to introduce a new scheme, which also reflects better what it 
> is, like sitemap:
> 
> 
>>A possible solution would be to add relative URL resolving to the Source
>>interface, so that the Cocoon source can use its own logic for this,
>>while the URLSource can use e.g. the java.net.URL class.
> 
> This would also be a solution. Perhaps we could do both. Introduce sitemap:, 
> to make the URI more standard. And add relativize and resolve to Source for 
> the actual handling. This way also fragment identifiers could be handled.

the block: protocol will remove the need for any absolute addressing
scheme. so cocoon:// will very likely be deprecatable at that point
since there will be no need for it (absolute uri dependencies *will* be
discouradged in favor of an indirect mapping scheme that allows
hot-redeployment and behavioral polymorphism of URIs)

I would be *strongly* against adding anything to the way we resolve
resources that will make it more static than what already is. Rather the
opposite: as soon as block are in place, I'll propose we deprecate
cocoon://. It felt wrong as soon as we introduced it, but we didn't have
any better idea on how to achieve the same functionality. Now we do.

>>>My ideas so far:
>>>The problem is, that you can't give a protocol and a relative URI. My
>>>idea would be to help to get an absolute URI. We use an input module,
>>>which gives back a prefix to the actual pipeline. The cocoon protocol
>>>will be handled like the file protocol. So you can either give an
>>>absolute URI, or use a relative uri, by prepending the prefix to the
>>>current pipeline.
>>>What do you think?
>>
>>I'm not following you here, maybe explaining with an example will help.
> 
> OK, problem would be I have a relative URI to my actual cocoon:... document. 
> An idea to get it absolute would be to have the document's absolute URI 
> accessible as input module. 

no, the idea is to not have *anything* absolute whatsoever, period!

The block protocol is a three-tier addressing scheme, not a two-tier one:

 block:role:path

which *is* an uri where

 protocol -> block
 body -> role:path

and we further divide body to

 - role -> the name of the "behavior" of the block we depend on
 - path -> the path inside that block (absolute to the root of the block)

there is *no* two-tier addressing that cannot be performed with a
three-tier model. but the opposite is not true: there are *many* things
you can do with an indirect addressing scheme that you can't do with a
direct one.

An example of this is so trivial that I leave it as an exercise to the
reader ;-)

Result: I vote -1 to any modification of the cocoon: protocol behavior
until we release Cocoon 2.1

-- 
Stefano.



Mime
View raw message