[kepler-dev] Proposed Future Kepler Configuration System

[Matt Jones]

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
>



-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Matthew B. Jones
Director of Informatics Research and Development
National Center for Ecological Analysis and Synthesis (NCEAS)
UC Santa Barbara
jones at nceas.ucsb.edu                       Ph: 1-907-523-1960
http://www.nceas.ucsb.edu/ecoinfo
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~