Re: [Kernel2.2] Source Resolving

[Pier Fumagalli]

On 31 Mar 2004, at 12:18, Carsten Ziegeler wrote:

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 :)

I don't think there are going to be more, as blocks libraries themselves can be represented as a directory (File) and a JAR archive (JarFile)... So, for resolution of sources _between_ block, nothing else should get in the way...

If we want to build the full resolver inside the framework itself, and therefore the "resolve" method in "Wirings" and "Wire" will accept "block:wiring:/path" instead of only "wiring:/path", then yes, I agree with you that source resolution should be closer (or same as) Excalibur's SourceResolver.

Only "issue" I might see with that is that Excalibur's Source doesn't have the "isDirectory()" and "children()" methods, so, well, I don't absolutely like it because it's prone to hacks.

Maybe a union of the two might be better?

Pier

smime.p7s
Description: S/MIME cryptographic signature