[kepler-dev] Proposed Future Kepler Configuration System

Tue Feb 3 20:01:02 PST 2009

Hi David,
You are reinventing the wheel here.  Configuration of
systems have been written time and time again.  I'm not saying
necessarily saying use Netbeans or Eclipse, but you would
be wise to review them and survey other systems.  Defining
your requirements as you have done in the forum is an excellent
first step.

BTW - The reason the Ptolemy uses such an arcane system was because we
wanted to try to push the Ptolemy notion of hierarchy and MoML and
"eat our own dog food".  While this was a successful experiment,
the result has been confusing for users other than the
initial developers.  Also, the Java developers really dropped
the ball with the UI.  Tcl had a much better UI and a
previous effort that we developed called Tycho was much
easier to configure.

Kepler has a simple configuration system in place already with
the bundles and the uiMenuMappings_en_US.properties files.
Maybe you need to make a stronger case as to why those
are not sufficient?

Also, the ISO codes are the way to go for internationalization.
Applying a different naming system will cause problems later.
Sticking with best internationalization practices is a win.

I think a configuration system is a good idea, but reinventing
one is not.

_Christopher

David Welker wrote:
> Hi Christopher,
> 
> Thanks for your suggestion. A couple of thoughts on your ideas regarding 
> closely integrating with Eclipse or Netbeans.
> 
> 1) The scope of your suggestion is much greater than the incremental 
> configuration project I had in mind. It goes quite a way beyond mere 
> configuration and perhaps has implications for distribution, integration 
> with other tools, how modules are defined and interact, how we build, 
> and how developers work. It is not clear to me to what extent one can 
> choose to just buy into these platforms incrementally, without more or 
> less converging onto the Netbeans or Eclipse way of doing things. This 
> would be a rather large, rather than small, effort. It would be a major 
> decision.
> 
> 2) To really integrate with Netbeans or Eclipse would involve very 
> significant refactoring of the GUI. (There will, of course, be some 
> refactoring of how the GUI is configured with the project I am 
> contemplating, but probably on a smaller scale.) My question is Ptolemy 
> in doing that sort of work? I could imagine a scenario (after careful 
> evaluation of costs and benefits) where Ptolemy and Kepler work towards 
> a common standard based on either Eclipse or Netbeans. But I think the 
> costs for Kepler are much higher if we were to try to go it alone 
> (because so many changes are implied in Vergil by such a move).
> 
> 3) I can definitely imagine benefits to closely integrating Kepler with 
> Eclipse or Netbeans. For example, allowing users to modify actor code by 
> right-clicking on it from inside of Kepler. It could also define a more 
> convenient distribution model, allowing us to more seamlessly provide 
> updates to users. I can also imagine costs associated with the 
> complexity of integrating Kepler into either of these ecosystems.
> 
> 4) If the goal is to simplify configuration, then integration with 
> Eclipse or Netbeans likely contradicts that goal. Configuration would be 
> more complicated, because both Netbeans and Eclipse have fairly complex 
> configuration systems in place. I could roll out a custom configuration 
> system that is simpler and easier to use much faster than we could 
> integrate with either the Eclipse or Netbeans ecosystem. So, any 
> decision to integrate with these ecosystems should be based on concrete 
> benefits provided by integrating with the tool sets available in these 
> platforms, not any illusions that this would simplify configuration.
> 
> 5) If we use either Netbeans or Eclipse as a platform, why we would not 
> be officially "blessing" one IDE over another, we would in fact be 
> favoring one over another. The best tools for making Netbeans plugins 
> and modules for Netbeans is Netbeans itself. The same is true of 
> Eclipse. We should realize that if we do decide to integrate with a 
> particular IDE, we are making one IDE much easier to use than others, 
> even while not officially preventing the use of other tools.
> 
> Overall, after an initial examination, I am somewhat skeptical that we 
> should be integrating with either Eclipse or Netbeans. I think it would 
> be a fairly large amount of work, would make configuration more complex 
> and not simpler, and would in a de facto way tie us to a particular IDE. 
> Right not, I am not entirely convinced that the concrete benefits I see 
> (mainly having to do with distribution of new modules and perhaps 
> integrating the code development capabilities of Eclipse or Netbeans 
> with Kepler/Ptolemy) are worth the work and added complexity. But, I am 
> definitely open and am willing to be convinced.
> 
> David
> 
> 
> 
>> 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