Jim Marino wrote:
On Jul 3, 2006, at 5:34 AM, ant elder wrote:
One of the big reasons for me is summed up well in Sebastien's proposal:
"This will get our community members involved in building the runtime
together and will lead to a wider knowledge base that makes it
possible to
quickly implement new functionality in the future. It will also build a
community knowledge base that is ready to help new community members
come on
board quickly."
I struggle with understanding the what and why of parts of the
sandbox code
and hope bringing small bits over one step at a time will help with
this.
Could you outline specifically what you don't understand. Perhaps we
could do another code walkthrough like we did about a month ago?
Why don't you like this approach? Sure it may take a bit more time
but if in
the long run we end up with more people understanding the runtime
that seems
like time well spent even if we end up with most of the trunk being just
whats in the sandbox today.
The key point is I like Jeremy's approach better. The thought of
merging M1 with the sandbox code (Sebastien's proposal) doesn't seem
to fit based on my technical knowledge of both code bases. More
importantly, Jeremy's approach strike me as better. Since I have
outlined my reasoning in previous posts (not just technical) why I
think it is better,I won't repeat them here, as it will just confuse
the ongoing threads.
My proposal is not to merge M1 and the core2 sandbox. I am proposing to
start a new fresh code stream and build the runtime through baby steps.
We may be able to reuse some pieces of existing code, but more important
is to engage our community in this exercise and integrate the new ideas
that will emerge from this.
Here's an example where I'm struggling with both M1 and the core2
sandbox and thinking that we can do better if we start with a new fresh
stream: our (recursive) assembly metadata model.
- M1 does not implement the recursive composition model and would
require significant changes to support it. Core2 is an attempt to
implement it but I'm not sure it's quite right, and also think that it
can be simplified.
- M1 used Lists to represent relationships, Core2 uses Maps, I think M1
was better since it allowed to keep the order in the relationships.
- Core2 only defines implementation classes for the model, I think we
should have interfaces + default implementation classes instead, like we
had in M1, to allow for alternate implementations of the model.
- Over usage of Java Generics breaks flexibility in some cases, for
example Component<I extends Implementation> will force you to recreate
an instance of Component to swap its implementation with an
implementation of a different type (and lose all the wires going in/out
of the component).
- Core2 defines ReferenceDefinitions (without bindings) and
BoundReferenceDefinitions (with bindings). IMO there are Reference types
and Reference instances and both can have bindings.
or Reference.
- I think that Remotable should be on Interface and not Service.
- Scope should be defined in the Java component implementation, separate
from the core model.
- Java and WSDL interfaces should be defined separate from the core
model, we need to support multiple interface definition languages
supported by plugins, not in the core.
- Implementation should extend ComponentType IMO instead of pointing to
it, and we may even be able to simplify and just remove Implementation.
Also I am not sure why we need to distinguish between
AtomicImplementation and CompositeImplementation.
- Support for Composite Includes is missing, this is a significant part
of the recursive composition model (half of it, one of the two ways to
nest composites).
This list is not exhaustive... Another idea would be to externalize
support for Composites in a separate plugin not part of the core service
model (since there may be other ways to compose services in addition to
an SCA composite, with Spring or other similar programming models), I'd
like to know what people think about that.
I just checked in sandbox/sebastien/m2-design/model.spi a set of new
interfaces. This is just an initial strawman to trigger a constructive
discussion and ideas on how to best represent the recursive model. I
also need help to define a scenario (not unit test cases, but an end to
end sample application) to help put the recursive composition model in
perspective and make sure we all understand it the same way.
Comments, feedback and help are welcome...
So, to turn it around a bit, as I've already outlined some of my
reasons for liking Jeremy's approach more, do you have additional
reasons other than you are having difficulty understanding the sandbox
code and your feeling it will be a worthwhile exercise in knowledge
sharing? Regarding the later, I think it's better (and more inclusive)
to make a concerted effort to modularize and bring people into the
sandbox code as that will allow all of the ongoing initiatives
(particularly the ones showing Tuscany value add) to continue
alongside the knowledge transfer.
Regarding the former, could you outline specifically what you are
having difficulty following in the sandbox code so I can try and
address it either through explanation or simplification of the code?
...ant
On 7/3/06, Jim Marino <[EMAIL PROTECTED]> wrote:
Why would we try this approach as opposed to the one Jeremy proposed,
i.e. moving what is already in sandbox to a branch or even trunk?
Since there are a number of initiatives people are already working on
in the sandbox codebase (e.g. Spring support, deployment,
conversations, data binding, OSGi support, support for new Java C&I
annotations, support for pluggable annotations) it is seems that
making improvements to that according to scenarios people are
interested in will be a nice way to move things forward involving as
many as possible.
Jim
On Jul 3, 2006, at 4:45 AM, ant elder wrote:
> On 6/30/06, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
> <snip/>
>
> 2. Stage the assembly of our M2 runtime.
>> I propose that we start a fresh stream for M2 and build the runtime
>> through
>> baby steps, in parallel with the scenario work. This will get our
>> community
>> members involved in building the runtime together and will lead to
>> a wider
>> knowledge base that makes it possible to quickly implement new
>> functionality
>> in the future. It will also build a community knowledge base that is
>> ready to
>> help new community members come on board quickly.
>
>
> This approach appeals to me. Could we just give it a try for a
> little while
> when everyone is back on Wednesday? If it doesn't work out then all
> the
> other code will still be available in SVN to try another approach.
>
> ...ant
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
