cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pier Fumagalli <>
Subject Re: [Kernel2.2] Source Resolving
Date Wed, 31 Mar 2004 11:09:13 GMT
On 31 Mar 2004, at 10:56, Carsten Ziegeler wrote:

> I just had some quick looks at the new kernel 2.2 and the
> first topic to discuss is source resolving :)
> Cocoon uses the excalibur source resolving package to resolve
> any resources (file, http, cocoon pipelines etc.).
> The kernel currently uses a similar construct
> but with new interfaces and implementations.
> In order to reuse what we already have and to be
> "more compatible" to Cocoon 2.0/2.1, I would suggest to use
> the sourcer resolver package here as well.
> Another reason is that we need a Source Resolver for the sitemap
> components anyway. Most sitemap components get the source resolver
> as a parameter in the setup (or act etc.) method.
> Now, I know that the original kernel should be as small as possible
> and if possible without references to any other projects which is
> in general great and ok, but I think for Cocoon it's better to use
> existing parts whereever possible.
> Ah, and if you think that one problem is that the sourceresolver
> package is hosted at avalon, we can/should solve this as well.

Carsten, i think I introduced a little bit of confusion calling a 
couple of things "Resource" and "Resolver"... Careful, those are 
"resource" resolution for infra-block wirings. What does it mean? That 
Wirings.resolve(String) or Wire.resolve(String) will NEVER resolve 
things like "http:...." or "ftp:...", not even "cocoon:...." unless 
those names are names of wirings specified in a block descriptor.

A sourceresolver must be implemented on top of this interface, 
providing resolution for "http:...", "ftp:...", "cocoon:..." <and> a 
new protocol called "block:..." which will fall back on the framework 
resource resolvers.

As Stefano said in his original [RT] on blocks, any source-resolved 
resource which need to fall back on blocks resolution will have to be 
something like:


The SourceResolver will have to look at the beginning (block:) and 
understand that in needs to resolve the resource on the block's 
resolver as "wiringname:...". If it begins with something else (cocoon: 
for example) it will have to resolve in a different way...

The Resolver interface specifies that there's no contract between name 
and the resource, maybe we could implement this in the 
o.a.c.k.DeployedWirings class, change the interface, or whatever! :-)

Sorry for the confusion...


View raw message