ant elder wrote:
On 3/25/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
[snip]
Jean-Sebastien Delfino wrote:
>
>> For example, the "variant implementation of the assembly model" has a
>> number of changes that coupled with what you describe above will
>> basically require a re-write of kernel.
>
> I have not committed yet this variant implementation of the assembly
> model as I just started to experiment with it yesterday. What I have
> in the sandbox at the moment is a set of interfaces defining an
> assembly model API, and a default implementation of these interfaces.
> The variant implementation that I'm talking about is a prototype of a
> different implementation of (a subset of) the same model interfaces,
> backed by Spring bean definitions. This will help illustrate how clean
> interfaces allow for alternate implementations of one or more modules,
> and facilitate the integration with a particular runtime environment
> (Spring in this case). I've just spent a few hours on this prototype
> so it's not really baked yet, but I'll commit what I have soon so that
> people can take a look if they are interested.
>
I just committed a few classes in sca/modules/bean and bean-test under
revision r522186 to show what I meant by a variant implementation of the
assembly model.
It looks to me like this code you've been doing in the sandbox now has
enough to illustrate a lot of the concepts that have been suggested for a
more modular kernel. How about we now talk about what you've done and
about
how further development of these ideas could happen in trunk? It
sounds like
everyone now agrees we need a more modular kernel, is everyone willing to
start doing this in trunk instead of this sandbox?
...ant
Ant,
Yes, what I have been doing in the sandbox probably has enough to
illustrate modularization of how we handle metadata (models etc.) in our
runtime.
Like I said in [1] I think some of this work should be done in trunk. I
also think that we need a working trunk and as discussed in [2] I'm not
advocating for a complete re-write of the kernel, so we may need to find
a way to do this modularization work incrementally. Here are some
initial ideas to help do this:
- Move some of these modules to trunk and evolve them in trunk, then
port pieces of the runtime that want to use them incrementally over
time, when people feel ready for it. For example we could start using
the model I have been proposing in the WSDL2Java tool, that does not
mean that kernel/core has to change right away.
- Move some of these modules in trunk, and adjust some of the model SPI
in trunk (made of classes) to implement the model interfaces that I have
been proposing, allowing kernel/core to continue to work with these
classes until somebody wishes to do the work to port it to the
interfaces. I'm not sure how practical it's going to be, but as usual
actually writing the code and trying it will help understand the
implications of this approach.
What's not in my sandbox yet (and which I would like to see prototyped
quickly to help have a concrete discussion on it) is a modularization of
the execution part of the kernel. For this to happen I think we need to
start looking at ways to assemble our SCA runtime kernel without using
SCA itself, as this is causing a sort of a chicken and egg problem at
the moment, and preventing modularization of the support for Java
components in particular since the kernel/core relies on it to assemble
itself.
I'm not sure about how to approach this second part of the
modularization work. I had indicated in [2] my intention to try first in
the sandbox (try to make the support for Java components a separate
module), but I'd very happy to work on it in the trunk if our community
feels that it's an acceptable approach.
[1] http://www.mail-archive.com/[email protected]/msg15725.html
[2] http://www.mail-archive.com/[email protected]/msg15978.html
Thoughts?
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
