Pier Fumagalli wrote: > > 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. > > > > 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! :-) > Ah, ok, I see. Good :) But couldn't the source resolver (the interfaces and the impl.) not also be used for this as well? I saw, you have an impl. for jars and one for files. This is more or less code duplication, I think. Of course, if there are only these two and not more than it might be ok. Hmmm :)
Carsten
