Woah. 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:
Contents 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: http://marc.theaimsgroup.com/?l=avalon-dev&m=107485031403277&w=2 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 resolved. 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? Yes? * MutableConfiguration is a type of Configuration * Existing code which uses Configuration could take advantage of MutableConfiguration via casting (nice for containers) No? * 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 options. It's good to be back. :) J. Aaron Farr SONY ELECTRONICS DDP-CIM (724) 696-7653 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
