[kepler-dev] More on packaging / organizing Kepler

[Edward A Lee]

Ptolemy does support plug-ins.  It supports them at multiple levels:

  - actors
  - directors
  - user interfaces
  - on-line documentation

The latter two are based on the "configuration" mechanism, which you
can use to create a separately branded application that includes
whatever subset of Ptolemy II you find useful.  A "configuration"
is itself a Ptolemy II model, so they are fairly easy to build...
The configuration defines what object is used to open and display
the contents of a file, for example, and what is displayed on the
startup splash screen, and what the help menus point to, etc.

I think the key issue is to design Kepler to maximize the leverage
it gets from existing Ptolemy II facilities, rather than just replacing
them wholesale.  This may require, at times, modifying the plug-in
mechanisms to make them more flexible.

For example, one of the user interface enhancements that Kepler needs
is a better browser for libraries in the left pane of a vergil window.
While current plug-in mechanisms make it easy to replace the entire
vergil window, they don't make it easy to replace just that pane.
Hence my previous email suggesting how to enhance the plug-in
capability so that a configuration can specify what goes in that
pane.

Edward

At 09:19 AM 3/24/2004 -0800, Shawn Bowers wrote:

>Hi all,
>
>I was wondering if there was any motivation to create a version of Ptolemy 
>that allowed for "plug-ins" (e.g., like in many Microsoft products, 
>Mozilla, and Protege, which has *many* very nice and fairly complex 
>plug-ins that have been created by various groups).
>
>It seems like this would solve a number of problems: (1) it wouldn't force 
>Kepler to keep a separate Ptolemy branch (i.e., everytime a new Ptolemy 
>version came out, Kepler would need to be reworked); (2) the Ptolemy 
>source would not need to be included with Kepler; (3) different 
>organizations could develop their own plug-ins and suite of plug-ins; (4) 
>it would reduce much of the management burden from Kepler developers; and 
>(5) it would minimize backward compatibility issues (unless a new Ptolemy 
>release forced this).
>
>In general, it is my understanding that the Kepler extensions (at least 
>currently) do not require changes to Ptolemy and are really "extensions" 
>-- if this holds so that the plug-in model is feasible, I think it would 
>be a much more elegant solution to many of the current problems.
>
>Anyway, I am not a Kepler developer, just an outside observer, but I just 
>wanted to throw the idea out there.
>
>Shawn
>
>
>_______________________________________________
>kepler-dev mailing list
>kepler-dev at ecoinformatics.org
>http://www.ecoinformatics.org/mailman/listinfo/kepler-dev

------------
Edward A. Lee, Professor
518 Cory Hall, UC Berkeley, Berkeley, CA 94720
phone: 510-642-0455, fax: 510-642-2739
eal at eecs.Berkeley.EDU, http://ptolemy.eecs.berkeley.edu/~eal