Carsten Ziegeler wrote:Gianugo Rabellino wrote:Carsten Ziegeler wrote:Ah, ok, I wasn't very clear :)
Now, I know that the original kernel should be as small as possible and if possible without references to any other projects
which is ingeneral great and ok, but I think for Cocoon it's better to use existing parts whereever possible.
Well, the balance will be hard to find, but I think that avalon source resolving cannot be used without importing all the heck of Avalon itself and its dependencies, so how would you plan to import it in the new environment without an almost complete rewrite?
First, I think we should use the interfaces (SourceResolver and SOurce)
from excalibur. Apart from the package name they have no dependency
to anything else at Avalon. And I think using these interfaces is
the key concern.
Then most of the implementation is "avalon free" as well.
Third, the package will be put to sleep over at avalon anyway as it
doesn't comply to the Merlin component standard, so it makes sense
to take over this source anyway.
-1
I think the kernel should be *clean* of avalon stuff and there will be an avalon sandbox for legacy.
Look at the good side of this: you can cleanup those interfaces with the knowledge we aquired from excalibur.
So, would you like that that the resolver provided by the framework could actually resolve "http:...", "ftp:...", "cocoon:..." and "block:wiring:..." or your preference is to keep it lean over there and only have "wiring:..." whilst having something ELSE to resolve the real protocols?
Pier
smime.p7s
Description: S/MIME cryptographic signature
