[kepler-dev] Proposed Future Kepler Configuration System

[David Welker]

Hi Matt and Everyone,

Thanks for the feedback.

I agree that we should evaluate existing configuration systems at 
consider their fit for our needs compared to a custom system. It could 
be that any of these existing systems is not a good fit or would 
actually take longer to utilize, so I think we should approach this 
evaluation with a totally open mind. Certainly, if you had an already 
implemented system that fit like a glove, that would be the way to go. 
To the extent that system doesn't fit so well or commits us to a 
particular technology that we are not certain we want to commit to or 
requires excessively verbose configuration files (something we should 
definitely move away from as much as possible) then we should consider 
sewing a custom glove that fits better, so to speak.

With respect to your point about using certain conventions to refer to 
language, I cannot say that I agree with you. I would prefer much 
simpler strings like, "english" instead of "en_US" or "englishUK" to 
"en_UK" or "german" to "de" or "japanese" to "jp." I think that spelling 
out directories is totally unambiguious and much easier to read and much 
easier to understand, especially for new developers. As Timothy 
anticipated, my original proposal in this regard was sure to not go 
unnoticed or unobjected to. May I suggest that we bring this issue to a 
vote and move ahead rapidly from there, whatever the results.

Finally, and most importantly, I agree with you that it is important to 
unify all the configuration information. For that reason, I definitely 
would appreciate developer effort in briefly documenting the remaining 
files that have not been documented thus far. I know that the 
.properties files beginning with ui have not been documented. I think 
that is fine, since I am well aware of those. What I am most interested 
in are any other configuration files that have not been documented. If 
anyone is aware of any additional files, listing them or, better yet, 
documenting them at the following URL would be greatly appreciated:

https://dev.kepler-project.org/developers/teams/framework/kepler-configuration/current-kepler-configuration/

Thanks!

David

> Thanks for undertaking this, David.  I agree with you that it would be
> extremely useful to consolidate the configuration files into a single
> system.
>
> I agree with Christopher that reutilizing an existing configuration
> system, even if it is not an exact match for all of our needs
> (especially the non-functional needs), would be far preferable to
> reinventing the configuration wheel.  At a minimum, I think we should
> utilize the fairly common practice of using ISO country codes to
> differentiate settings directories rather than arbitrary language
> strings. The Java properties system has some well-known conventions
> for differentiating properties and bundles intended for different
> languages, so we should study that common case carefully before
> deciding to go with another.  Looking at how Eclipse handles
> configuration would be useful too, although I suspect it is a
> byproduct of use of OSGI.
>
> I think one thing to avoid is a partial migration to a new system.
> That is the trap that got us into this configuration mess in the first
> place. Several people have deigned to 'redesign' the configuration
> system, but they each failed to convert all configs to the new system,
> with the result of simply adding complexity. So, if you undertake
> this, I think you need to commit to converting all existing code
> (yours and others) in the trunk and modules to use the new
> configuration system.  Otherwise, this new system will just further
> complicate an already messy situation.
>
> Regards,
> Matt
>
>
>
> On Mon, Feb 2, 2009 at 3:12 PM, Christopher Brooks
> <cxh at eecs.berkeley.edu> wrote:
>   
>> Hi David,
>>
>> Thanks for summing up the current configuration details.
>>
>> I suggest reviewing how Eclipse and Netbeans do platform rich client
>> platforms (RCP).  Is it necessary to invent yet another system?
>> You may want to compare and contrast your design with prior art as
>> they have addressed similar issues.
>>
>> _Christopher
>>
>> David Welker wrote:
>>     
>>> Hello everyone,
>>>
>>> I have done a basic review of the current Kepler Configuration System and
>>> have developed a proposal for a new Kepler Configuration System.
>>>
>>> Please see my proposal here:
>>>
>>>
>>> https://dev.kepler-project.org/developers/teams/framework/kepler-configuration/proposed-future-kepler-configuration-system/
>>>
>>> Also, I have briefly documented a subset of the existing configuration
>>> files. If anyone wants to add to or elaborate on that documentation, they
>>> should feel free to do so. That basic documentation is available here:
>>>
>>>
>>> https://dev.kepler-project.org/developers/teams/framework/kepler-configuration/current-kepler-configuration/
>>>
>>> Anyway, I am moving forward with a prototype that implements my proposal.
>>> However, in parallel, I would like to have a discussion about how people
>>> feel about the proposal and any additional configuration-related features
>>> that they would like to see.
>>>
>>> Thanks!
>>>
>>> David Welker
>>> _______________________________________________
>>> Kepler-dev mailing list
>>> Kepler-dev at kepler-project.org
>>> http://mercury.nceas.ucsb.edu/kepler/mailman/listinfo/kepler-dev
>>>       
>> --
>> Christopher Brooks (cxh at eecs berkeley edu) University of California
>> CHESS Executive Director                      US Mail: 337 Cory Hall
>> Programmer/Analyst CHESS/Ptolemy/Trust        Berkeley, CA 94720-1774
>> ph: 510.643.9841 fax:510.642.2718             (Office: 545Q Cory)
>> home: (F-Tu) 707.665.0131 (W-F) 510.655.5480
>> _______________________________________________
>> Kepler-dev mailing list
>> Kepler-dev at kepler-project.org
>> http://mercury.nceas.ucsb.edu/kepler/mailman/listinfo/kepler-dev
>>
>>     
>
>
>
>