Jim,
My comments inline
Jim Marino wrote:
On Mar 23, 2007, at 8:52 PM, Jean-Sebastien Delfino wrote:
Davanum Srinivas wrote:
Sebastien,
Can you please explain to everyone the purpose of this svn area and
what you are planning to do here?
thanks,
dims
Dims,
In the sandbox, I am trying to demonstrate a modular Tuscany kernel
that can support what I described in this thread:
http://www.mail-archive.com/[email protected]/msg15782.html
I'm working on this in sandbox/sebastien/java/sca/modules.
Basically I'm trying to come up with a set of black-box modules, with
minimum SPIs, minimum inter-dependencies, covering the following
aspects:
- modules/assembly - SCA core assembly model
- modules/policy - SCA Policy model
- modules/scdl - SCDL support (reading/writing the model from/to SCDL)
- modules/builder - A prototype of a different API to the assembly
model (showing how the same model can implement multiple interfaces)
- modules/java and java-scdl - SCA Java model and SCDL support for it
- modules/wsdl and wsdl-scdl - SCA WSDL model and SCDL support for it
- modules/crud and crud-scdl - a prototype of a simplistic SCA
component implementation type, to help validate the pluggability into
the model and the SCDL support
- modules/http http-tomcat and http-jetty - embedded Tomcat and
Jetty, I want to experiment with a binding (probably based on HTTP)
and I'm not sure which to pick between Tomcat and Jetty for that so I
pulled these two modules in as well and put in modules/http a small
ServletHost interface that will help integrate them.
I'm also just starting to prototype a variant implementation of the
assembly model, to see how a fairly different model implementation
can be swapped without breaking the other pieces (using the assembly
model API interfaces).
So this first set of modules covers part of the SCA metadata/model
story. Next I'd like to start looking at the execution runtime and
see how the execution part of kernel/core can be split in multiple
modules as well. I'd like to see how the SCA Java component support
can be extracted as a separate module for example.
I also copied to my sandbox a top-down build structure including end
to end samples and integration tests, which I'd like to use to
validate that these ideas and this assembly of modules hold together.
So, as I said in the above thread, I'd like feedback, ideas or help
with this work. People have asked for a more concrete proposal and
more details, the proposal is starting to take shape, and I'm happy
to continue to work on it wherever the community feel it should be done.
>From looking at the above description and the commit history it seems
you have forked the code.
I copied some of the Tuscany code to my sandbox to work on the
modularization proposal, as I obviously didn't want to start from scratch.
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.
With respect to "a re-write of kernel" I hope we can avoid re-writing
it... I'm not sure why you're saying that this will require a re-write.
Now that I've made some progress on the metadata handling (models etc),
as I already said in my previous email, my intention is to start looking
at how to modularize the execution part of the kernel, and I obviously
don't want to restart it from scratch. I'm hoping to have to adjust only
some of the runtime builders and minimize changes in the rest of the
kernel core. It's not really serious to speculate anyway, I think that
prototyping this work will actually tell what's required.
What are the reasons for these changes? Couldn't trunk be
incrementally improved? Are there any plans for merging this with trunk?
As you said yourself when you asked me to continue to work on this in a
sandbox instead of trunk in:
http://www.mail-archive.com/[email protected]/msg15726.html, the
approach taken is significantly different than the design we have in
trunk. I am prototyping a different design, with independent modules,
minimal interfaces between them, and no circular dependencies between
the modules.
It's not up to me to decide on any plans to merge this with trunk. I'm
hoping that our community will see value in this work and will allow
some of these ideas to be applied to the trunk at some point, and
perhaps this can be done incrementally.
Is this a revolution?
Jim
The approach that I'm prototyping is different from what we have in
trunk and some of the design changes are revolutionary in nature, but I
don't know if that makes it a revolution. At this point I'm simply
trying to show that approach through concrete work and code.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
