[kepler-dev] Proposed Future Kepler Configuration System

Mon Feb 2 22:21:15 PST 2009

Hi David,

    Thanks for your great work on new build system and this proposal.

    I want to add one more 'Desired Property' for new configuration 
system: support Kepler sharing among multiple users on one machine. The 
detailed info and the bug for old build system can be found at 
http://bugzilla.ecoinformatics.org/show_bug.cgi?id=3694 .

Best wishes

Sincerely yours

Jianwu Wang
jianwu at sdsc.edu

Scientific Workflow Automation Technologies (SWAT) Laboratory
San Diego Supercomputer Center 
University of California, San Diego
San Diego, CA, U.S.A. 

David Welker wrote:
> 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
>>>
>>>     
>>
>>
>>
>>   
>
> _______________________________________________
> Kepler-dev mailing list
> Kepler-dev at kepler-project.org
> http://mercury.nceas.ucsb.edu/kepler/mailman/listinfo/kepler-dev