Leo Sutic wrote:
From: Niclas Hedhman [mailto:[EMAIL PROTECTED]
On Thursday 29 January 2004 05:49, Leo Sutic wrote:
I propose to:
1. add the following MutableConfiguration interface to framework (see below).
2. Add the getMutableChild and getMutableChildren methods to the DefaultConfiguration class.
3. Have DefaultConfiguration implement the MutableConfiguration interface.
+1 from me.
I vote "No".
I take that as a -1 VETO.
Why should the component be allowed to change its configuration object?
This has ***never*** been proposed. Nowhere have I *ever* stated that the MutableConfiguration should be passed in to the Component in the configure method, nor that it should be part of the Configurable contract, or any lifecycle contract at all.
However - the proposed addition of this to the framework API is inconsistent with this position.
In my original argument for this interface, I specifically state that this is ***NOT*** part of the proposal. If we, sometime in the future would like to pass in MutableConfigurations instead of Configurations, we sure can vote about that, but for now that's simply not an issue.
But placing the interface in framework API makes it an immediate and present issue for me. In particular - adding something to the framework API *implies* something in terms of the overall framework contract - and implication that we cannot easily back away from once released.
Argument is here: http://marc.theaimsgroup.com/?l=avalon-dev&m=107485031403277&w=2
"Here you go Mr Component, I have provided this for you, now live with it!"
"Here you go Mr Component, fill in your current configuration here."
Scribble scribble scribble...
"Thank you Mr Component."
This can archived independently of the framework API. Lets' assume the Mr Component is handling the management of another component. Mr Component gets log enabled, configured, serviced, etc. Part of the servicing process is to supply Mr Component with a MutableConfiguration. Perhaps Mr Component presents this via a web page where Mr User changes things. Mr Component then interacts via a MutableConfiguration interface to propagate changes.
The important point here is that we are not discussing framework aspects - we are discussing a separate and distinct service - and this directly impacts on the question concerning the location of this service interface and potential implementations of that interface.
Stephen.
--
|------------------------------------------------| | Magic by Merlin | | Production by Avalon | | | | http://avalon.apache.org/merlin | | http://dpml.net/merlin/distributions/latest | |------------------------------------------------|
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
