Hi,
I don't get a formal vote, but as an embedder it is extremely painful
to consume and embed a new level of code when the SPI layer
(that's supposed to insulate embedders) is changing as often as the
underlying kernel implementation. At the moment, the current
SPI layer might as well be invisible.
I'm not looking for n-1 compatibility in the SPI layer. I'm not
expecting zero changes in the SPI layer over time. I am
expecting increasing stability over time, which I do not observe,
and have not observed for some time. The stable branch is helping
in this regard, but I think more will be needed in order to allow
an embedder to pick up the function they need.
In reading over the related email threads from which this spawned, I
would certainly benefit from a decomposition of the kernel as described.
There's lots of good work going on in this project, but not all of it is
applicable when embedding into an existing runtime. The work on a
distributed SCA Domain is an example. I think it's good for that piece of
work to continue. The kind design that's proposed for this decomposition
will enable the movement of stable new function from the head into the
stable branch. As it is now, the stable branch will have to consume
everything from head and then stabilize it. That's not a viable model
moving forward.
A decomposition would also enable me to ignore pieces
of function forever, or until it's ready. A clean model definition, which
enables plug replace-able parts of the kernel is exactly what is needed.
It enables the use of the model at various integration points of an existing
runtime. That is, a clean model definition that doesn't change every day.
2 cents from an imbedder.
Dave
----- Original Message -----
From: "Meeraj Kunnumpurath" <[EMAIL PROTECTED]>
To: <tuscany-dev@ws.apache.org>
Sent: Tuesday, March 20, 2007 11:46 AM
Subject: Re: [VOTE] Rewrite kernel model to be based on interfaces
Hi,
I would like a more elaborate explanation on what is meant in this context
by interfaces, factory classes and separate implementations. As we are
now, our model classes just encapsulate state, with hardly any behaviour.
We quite nicely separate model from the runtime artifacts by moving
behaviour to controller classes that translate the model to runtime
artifacts. So, if the model classes are just state, why would we want to
define interfaces for them and separate implementations, as there is no
behaviour to be abstracted.
Also, there have been a lot of work that has happened in trunk in the last
month or so, in terms of seprarating the physical and logical aspects of
the model. We need to take into consideration the impact of this approach
on the physical model work, which is very much nearing completion now with
the federated deployment story.
At this stage by inclination would be to go -1, as I can't see a
compelling reason for changing the current design.
Ta
Meeraj
From: Jeremy Boynes <[EMAIL PROTECTED]>
Reply-To: tuscany-dev@ws.apache.org
To: tuscany-dev@ws.apache.org
Subject: Re: [VOTE] Rewrite kernel model to be based on interfaces
Date: Tue, 20 Mar 2007 07:25:15 -0700
On Mar 20, 2007, at 7:23 AM, Jeremy Boynes wrote:
The current model is based on simple POJOs. Sebastien has proposed
rewriting the configuration model to be based on interfaces with
separate implementation and factory classes. This will have a major
impact on the kernel code and all extensions. This vote is not about
what is in the model, it's is about how the model itself is implemented.
[ ] +1 we should do this
[X] -1 keep things as they are
My opinion.
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
_________________________________________________________________
Get Hotmail, News, Sport and Entertainment from MSN on your mobile.
http://www.msn.txt4content.com/
---------------------------------------------------------------------
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]
