Separate the GUI from the execution engine.
The GUI needs to be separated from the execution engine so that it is easy to develop specialized GUIs for a particular domain. The path for developing a new GUI that uses the execution engine should be well defined. For example, if one wanted to develop a new GUI with a different technology (i.e. Flex) or for a very specialized domain there should be a well-defined path for proceeding.
This is a Kepler/CORE grant requirement.
Updated by Chad Berkley about 14 years ago
I've gotten off to a good start isolating the execution engine itself. I've added a target to the build called 'build-ptolemy-execution-engine'. It will build two jar files. One with just the ptolemy moml parsing and workflow execution facilities. The other with just the classes for the base ptolemy actors and directors. More classes may need to be added in the future, but right now these two jars represent the minimum of what kepler needs to use the ptolemy execution engine. It should be noted that when all of ptolemy is jarred, it is 143MB. The execution engine jar file is <1MB and the actor jar file is <2MB.
I have also created a basic API for this in kepler. org.kepler.ExecutionEngine (currently in loader) allows other classes to submit a workflow for execution in either the current thread or in a new thread. It also allows for the addition of ExecutionListeners and the run methods return the Manager for controlling runtime execution. This class will probably need to be extended a bunch, but the basics are there and it does work. I added a junit test to test its functionality. You can run 'ant test -Dmodule=loader' to see it run.
After running 'ant build-ptolemy-execution-engine', you can run the following command to see it work:
Updated by Christopher Brooks about 14 years ago
Ptolemy has always made a distinction between the execution engine and
the GUI. Clearly defining any issues in Kepler with this separation would
be useful. I believe one issue surrounded using graphical actors such as
the plotter, but I don't fully understand the details.
Also, defining a measure of success for "Separate the GUI from the execution
engine" would help. The Triquetrum project has worked on some of
the separation of the various pieces of the execution engine. For example,
and then start to add the domains.
For example, not all users of an execution engine will necessarily want moml.
I'm interested in working on this, and after Ptolemy II 8.0 is out I'd like
to reorganize the Ptolemy packages to better support modularization.
I'm marking this as an enhancement, and am not so sure this is a requirement of