cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carsten Ziegeler" <cziege...@s-und-n.de>
Subject RE: [Kernel2.2] Source Resolving
Date Wed, 31 Mar 2004 11:18:57 GMT
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


Mime
View raw message