Mailing-List: contact dev-help@avalon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Avalon Developers List" <dev@avalon.apache.org>
From: "Leo Sutic" <leo.sutic@inspireinfrastructure.com>
To: "'Avalon Developers List'" <dev@avalon.apache.org>
Subject: MutableConfiguration
Date: Wed, 4 Feb 2004 11:11:52 +0100
Message-ID: <007401c3eb07$50473c10$0801a8c0@lagrange>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
In-Reply-To: <200402040740.04425.niclas@hedhman.org>
Importance: Normal

> From: Niclas Hedhman [mailto:niclas@hedhman.org] 
>
> is your use case really desirable to promote as 
> the way to go. Right now, I don't feel like it is.

Niclas,

whether my use case is the way to go or not is *not relevant*.
I didn't ask you to validate and endorse the design of my use 
case, I asked you to endorse my design of an interface abstraction
of DefaultConfiguration.

What is relevant is whether the MutableConfiguration interface
makes sense - not if everything I intend to do with it does.

Yes, we can have a ComponentConfigurator, but seriously, why
do I have to solve the problems of:

 + Custom GUI configuration of components

 + Component configuration persistence

when ***neither are part of the proposal***, and both are "well, 
you can use MutableConfiguration for this, for example..."?

I proposed MutableConfiguration, with a rationale that was
***separate from any use case***. Then you asked me for a use case. 
I gave it, as well as I could.

Now you turn around and say that I have to evolve the use case
into something industrial-strength and include it in the proposal
before you'll consider MutableConfiguration.

You have also managed to drag into this the issue of how voting
is done at Avalon.

Niclas, you're seriously changing the equation for me. I had
always thought that it was easier to get things into framework
than to fork framework. Your insistence on my expanding the proposal
beyond any reasonable scope has made the proposal route take about
one and a half weeks and counting, while a fork would take 
about 1.5 minutes, and the results would be equivalent. A fork 
would also completely halt any chance of any of my work becoming
open source.

/LS


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