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]

Reply via email to