The idea that Leo Simmons put forth brought about some thinking on my part. The key issue here is *simplicity*. What is going to make component writing more simple? The thing is the definition of simplicity is a moving target. What is simple in one environment is a real PITA in another environment.
Add to that the reality that true simplicity means hiding complexity. In this case the idea brought forward was a sort of "active configuration". While my security risk alarm bells are going off, I can't completely dismiss the idea due to improving the developer's life.
Why was XML originally used as a backing for the configuration object? Because it was easy to implement. So the original decision for simplicity was for our ease instead of the administrator's or the component developer's. The net result is that we have the configuration object which is still very useful, but requires some work on the component writer's end to use effectively.
We have received a number of compliments on the usability of the configuration interface, esp. from people who prefer the passive configuration that Avalon uses. We also know that some people prefer active configuration, and as such develop their components more like JavaBeans with setters/getters for the configuration points. Some have gone so far as to move all configuration to the constructor (Pico Container).
So the question remains to be asked: what is simpler, more acceptable, to our users? How do we handle reconfiguration (which we don't at the moment)? I don't think any of us knows the answer to that, because the answer will be almost as varied as the number of users we have.
The impetus behind scripted configuration seems to be administrator simplicity, or something along those lines. There are also some aspects of configuration that must be determined at runtime. XML cannot do this, but I feel that scripted configuration probably isn't the answer either.
We could use a number of backing formats for our configuration information, and they would all have their plusses and minuses. Unless we provide a GUI tool to allow the adiminstrator to update the settings, no solution will be truly simple for the administrator. So what could be done in a nice generic way? Hmmm. There is this standard called JMX which might be able to help in this regard.... However we don't know enough about it right now.
So what we need is not only to look at our side of the coin, but the component writer's and the administrator's side of the coin. JMX is only an option if we can generate the JMX MBeans for configuring the individual components automatically. We would be further from a simple solution if we have to write a JMX component by hand for each Avalon component.
In the end, once we have one or two possible solutions, I think one of the best things we can do is to involve our users. Put up some explanation of the alternatives, and have an informal vote (an oppinion gathering vote) to assess where our users are. While the votes are not binding and we can still do whatever we want, we will at least be informed of what will be easiest for our users. We might even be pitched a couple alternatives that we haven't thought of before.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
