Comments inline, thanks for some of the clarifications...
On Jul 5, 2006, at 12:43 PM, Jean-Sebastien Delfino wrote:
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.
It may be able to use a bit of simplification, but why is that an
argument to start over? Why not have the community leverage and
refactor it? That would seem to be much more inclusive since it would
allow a lot of the existing initiatives to proceed and be used to
help drive the simplification.
- M1 used Lists to represent relationships, Core2 uses Maps, I
think M1 was better since it allowed to keep the order in the
relationships.
Some specific reasons would be good here. Also, I hardly think this
is a reason to start over.
- 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.
The model contains no implementation behavior, it's just a set of
dumb data objects, so interfaces seem superfluous. If you really
wanted to override setter/getter behavior (perhaps for notification,
although I don't understand why one would do that in a runtime as
opposed to tooling) the classes can always be subclassed. Regarding
alternative implementations of the model, what use cases do you have
in mind? The base SCA model shouldn't change that much (it's in the
specification) so I imagine most people will just use the loaders
that come with Tuscany do load the non-extension parts. And when the
spec model does change, writing StAX loaders is dead trivial and well
understood by Java developers (StAX is being included in the JDK).
For extensions, configuration, etc., the framework Jeremy created
supports a pluggable databinding mechanism so SDO, JAXB, XStream,
etc. can *all* be used to load extensions.
Again, though, the fact that the model does not use interfaces is not
a reason to jettison the substantial amount of capability already in it.
- 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).
Not at runtime. This will work fine. Could you outline the specific
use-case you have in mind?
- Core2 defines ReferenceDefinitions (without bindings) and
BoundReferenceDefinitions (with bindings). IMO there are Reference
types and Reference instances and both can have bindings.
or Reference.
Great. Why can't we work on a "proposal"/modification to extend/
change core2 and see what it looks like together?
- I think that Remotable should be on Interface and not Service.
Service can be on both I believe. Unfortunately, annotations cannot
be restricted to interfaces in Java, though.
- Scope should be defined in the Java component implementation,
separate from the core model.
No, scopes are a general and very useful concept across
implementation types, e.g. I may want to have a Groovy script that is
conversational, bound to a session or module scoped. In the spec
group, we also decided to keep a general concept of scopes and leave
the specifics to individual language bindings. That's kind of what we
have in core2 today. I say "kind of" since our intent is to provide a
fully extensible set of scope containers. The one issue we are having
that needs fixing is Scope is an Enum and those can't be extended in
Java, so we need to look for an alternative.
If you have some thoughts on how to solve this issue, I'd be
interested in talking about them.
- 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.
Yep that's been brought up and a good way to engage. Jeremy and Ant
had some ideas on this so perhaps the three of you could work
together on that?
- 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.
All great feedback for improving core2. Jeremy had some reasons for
this so I'll let him speak up.
- 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).
Yes, because those were a recent addition to the spec. Again, this
would be a fantastic way to add value to core2. Can you help?
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.
Yes we have a specialized Spring composite type. We could entertain
making composite a separate implementation type, although I think
that may blow the complexity of the core through the proverbial roof.
Let's try it though. Maybe the best way to do this is make a copy of
core2 and start moving packages around and set what happens? My one
recommendation on this would be do first look at separating API from
SPI per Jeremy's suggestion posted in a previous email.
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...
Great, why don't we compare that model and try and see what happens
when we fit it into core2? Could you summarize the main differences?
To summarize, I think all of the issues you laid out are a reason to
engage and start from core2, not afresh. By doing so, I'm sure your
suggestions will lead to substantial improvements in what we have
today and help the broader community implement things they are
interested in.
Jim
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
