MutableConfiguration

[Leo Sutic <le...@inspireinfrastructure.com>]

All,

in the discussion-but-was-supposed-to-be-a-vote of the
MutableConfiguration 
interface some questions were raised regarding its usefulness,
correctness,
etc. I'd like to clarify my arguments for that interface.


WHAT IS IT?
-----------
Put simply, the MutableConfiguration interface is the interface
abstraction
of the DefaultConfiguration class. So far, we have had:

   Configuration        - interface - read-only
   DefaultConfiguration - class     - read-write

So if one wanted to only expose the read-only parts of a
DefaultConfiguration,
one would specify that a Configuration was passed. However, there are
times
when one wants to pass around a writable configuration object. So far,
the
obvious choice has been to pass around a DefaultConfiguration instance.
But
I would prefer if an interface could be passed around, instead of
locking
myself to a specific class. This makes for lower coupling.


WHAT IS IT NOT?
---------------
The MutableConfiguration interface has nothing to do with lifecycle
extensions,
or component persistence. While one surely can design such systems with
the
interface, the existence of the interface does in no way lock us into
having
to use it when designing the persistence mechanism.

I also do not propose that the component persistence mechanism that I
use be
made part of framework. I merely brought it up to illustrate how *I*
intend to
use the interface. Another use would be internally in a container: when
the 
container wants to alter a configuration before giving it to a component
and
doesn't want to pass around a concrete class to the parts doing the
alterations.

The interface is not a part of the container-component contract, as it
does
not exist in any of the lifecycle interfaces. In the future, should we
decide
to create new framework-level interfaces, it may - but that's for the
future,
and then only if a case can be made for it.


WHY PUT IT IN FRAMEWORK?
------------------------
Because DefaultConfiguration, which is the (I believe) by far most
commonly 
used example of a mutable configuration object, is in framework. Putting
the interface in Excalibur would mean that the class that is the prime
example of an implementation of it would not implement the interface.
This
makes no sense.

I have no problem putting it in avalon-framework-impl instead of -api, 
though.

/LS


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org

Re: MutableConfiguration

[Stephen McConnell <mc...@apache.org>]

Leo Sutic wrote:

> WHY PUT IT IN FRAMEWORK?
> ------------------------
> Because DefaultConfiguration, which is the (I believe) by far most
> commonly used example of a mutable configuration object, is in
> framework. Putting the interface in Excalibur would mean that the 
> class that is the prime example of an implementation of it would 
> not implement the interface. This makes no sense.

Good point.

> I have no problem putting it in avalon-framework-impl instead of -api, 
> though.

But I'm not OK with this. Mixing together an interface and the 
implementation means that any implementation of that interface would 
need to drag in all of those XML dependencies implied by the implementation.

However, putting this into something like avalon-framework-spi would 
seem to me to make a lot more sense.  What would make this a slam dunk 
question for me would be an alternative implementation that used the 
interface (Alex - any thoughts on the viability of backing this 
interface with Eve?).

Stephen.

-- 

|------------------------------------------------|
| Magic by Merlin                                |
| Production by Avalon                           |
|                                                |
| http://avalon.apache.org/merlin                |
| http://dpml.net/merlin/distributions/latest    |
|------------------------------------------------|

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org