avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Farr, Aaron" <Aaron.F...@am.sony.com>
Subject MutableConfiguration Proposal Summary
Date Wed, 04 Feb 2004 19:30:28 GMT

I finally finished reading the MutableConfiguration thread(s).  Leo is
right, Gump might be a TLP before this gets done! :)  Anyway, here's my take
on a number of the issues presented:

1. Comments on the Proposal and Implementation Details
2. Original Proposal:  MutableConfiguration
3. Concerns with MutableConfiguration Proposal
4. Tangents
5. Summary

1. Comments on the Proposal and Implementation Details

In Avalon, we love to discuss things to death.  It's amazing how verbose
this community is. :)  That's not necessarily bad, but it can be frustrating
at times.  Leo's initial proposal was very simple but, not unexpectedly, got
caught up in use cases, implementation discussions, and other tangents.  For
my sake at least I'll be trying to summarize the proposal and various ideas
on the table throughout this email.

2. Original Proposal:  MutableConfiguration

Leo's original proposal (or clarification) is at:

The interface is for Containers and other privileged extensions and not part
of any lifecycle interface or component contract.  The fact that it could be
someday or that it brings up all sorts of related topics (see tangents
below) has spurred some healthy discussion.  However, keeping to Leo's
original and simple idea, there are still a couple of concerns which need

3. Concerns with MutableConfiguration Proposal

  a) Where does it belong?
     * avalon-api
     * avalon-spi
     * avalon-impl

I don't think avalon-api is a good idea.  I don't like the idea of a one
class group (avalon-spi), but if we identify other interfaces which belong
there, then that's where it belongs.  In the meantime, we can easily add
MutableConfiguration to avalon-impl now and then worry about defining
avalon-spi later.

Oh, and I think Stephen's issues with excalibur-configuration have merit,
but it's been too long since I looked at that package or thought about a
solution and I don't see that as essential to this proposal.
  b) Should MutableConfiguration extend Configuration?
      * MutableConfiguration is a type of Configuration  
      * Existing code which uses Configuration could take advantage of
MutableConfiguration via casting (nice for containers)
      * Existing code which uses Configuration could take advantage of
MutableConfiguration via casting (bad for components)
      * Are there other reasons?

This is the only thing holding me up from a +1.  I would just like to better
see the options and consider the consequences.

As far as I can tell, these are the two main concerns with the proposal.
Yes, there are many other ways to do something like this, but Leo has
accurately pointed out a flaw in the current design and adding something
like MutableConfiguration to avalon-impl could be done without impacting ANY
code dependent on Configuration or DefaultConfiguration.

4. Tangents

This is where the proposal got off track.  None of these issues need to be
tied to MutableConfiguration or the vote.  They can and should be discussed
in separate threads, though I would suggest waiting until we get
MutableConfiguration worked out.

  a) MutableConfiguration vs DynamicConfiguration
  b) Configuration events and change notification (listeners)
  c) Reconfigurable interface (defining and implementing)
  d) Configuration persistence implementations
  e) Excalibur-configuration
  f) Plugging similar holes in Context and ServiceManager
  g) some other ones I'm sure I missed...

5. Summary

To reiterate:

The proposal is simply to add a MutableConfiguration interface to the
framework which defines the methods already implemented by
DefaultConfiguration.  This would allow containers and extensions (NOT
components) to work with an interface and not an implementation.  This is a
Good Thing.  The two outstanding concerns are (1) where to put it and (2)
should it extend Configuration.  I think it should be put into avalon-impl
for now and then we can begin to think about an avalon-spi.  As for
extending Configuration, I'm not exactly sure yet and I want to consider the

It's good to be back. :)

J. Aaron Farr
  (724) 696-7653

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

View raw message