RE: Objective of the following sandbox - tuscany/sandbox/sebastien/java

[Meeraj Kunnumpurath <M....@voca.com>]

 

>> -----Original Message-----
>> From: Jim Marino [mailto:jmarino@myromatours.com] 
>> Sent: 24 March 2007 07:34
>> To: tuscany-dev@ws.apache.org
>> Subject: Re: Objective of the following sandbox - 
>> tuscany/sandbox/sebastien/java
>> 
>> 
>> 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/tuscany-dev@ws.apache.org/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. 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. What are the 
>> reasons for these changes? Couldn't trunk be incrementally 
>> improved? Are there any plans for merging this with trunk? 
>> Is this a revolution?
>> 
>> Jim
>> 
>> 
>> 
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>> 
>> 
>> This message has been checked for all email viruses by MessageLabs.
>> 
I would like to know how this would impact all the work we have done in
the last couple of months on trunk in terms of separating the logical
and physical. From, a technical perspective, Sebastien's proposal is
drastically different from what we have now in trunk. So a merge into
the trunk is not going to be practical. Which means, if we decide to go
with Sebastien's proposal, we will be starting from scratch and throwing
away a lot of work that has been done in the last two months. 

I am willing to go with it, if I am some convinces me about what is
wrong with what we currently have in trunk, rather than what is good
about Sebastien's proposal. It is laudable, Sebastien wants to discuss
his proposal within the community. However, when there were discussion
threads on federation, logical/physical separation, management etc, the
only two people who actively participated in the discussions were
Jeremy, Jim and myself. Now we have a proposal that is going to throw
away a lot of the work some of us have put in, without even taking into
consideration what has happened in the trunk for the last couple of
months.

Ta
Meeraj


*****************************************************

    You can find us at www.voca.com

*****************************************************
This communication is confidential and intended for 
the exclusive use of the addressee only. You should 
not disclose its contents to any other person.
If you are not the intended recipient please notify 
the sender named above immediately.

Registered in England, No 1023742,
Registered Office: Voca Limited
Drake House, Three Rivers Court,
Homestead Road, Rickmansworth,
Hertfordshire, WD3 1FX. United Kingdom

VAT No. 226 6112 87


This message has been checked for all email viruses by MessageLabs.

---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org