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.
WDYT?
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:
block:wiringname:...
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...
Pier
smime.p7s
Description: S/MIME cryptographic signature
