Triquetrum/CapeCode

CapeCode

This intro to be corrected/extended by Christoper or someone else with real knowledge on CapeCode.

CapeCode is a project of the UC Berkeley CHESS group, who are also the originators of Ptolemy II. CapeCode is related to the domain of IoT, implementing assemblies of accessors to interact with connected devices in a well-defined way, reusing formal concepts from Ptolemy II's actor system.

Supporting CapeCode actors in Triquetrum's editor

As in other cases where we want to extend Triquetrum with extra actors, adding CapeCode actors consists of 2 main actions :

• providing the actor implementations in a way that is accessible by the editor and execution runtime
• defining editor palette contributions for them

The CapeCode actors that we consider here are JSAccessor actors, whose concrete behaviour is implemented in JavaScript. Adding CapeCode actors in a Triquetrum installation then requires at least the following :

• having the JSAccessor implementation (+dependencies) in the Triquetrum platform and being able to locate and load the JavaScript files that define the actor implementations. This is tricky business, especially when we want to remain compatible with native (non-OSGi) Ptolemy II approaches to load files from its class path.
• being able to read actor library definitions from CapeCode hosts and files and to add them to the editor palette. Ideally this should work without needing to restart the editor for each change in the CapeCode configuration.

In the text below we'll describe an approach to support CapeCode contributions to the editor palette.

Loading palette contributions via OSGi services

The traditional approach to define the graphical editor's palette is via extensions in the plugin.xml files of one or more palette configuration bundles.

This fits well with standard Eclipse practices but has some disadvantages as well, such as :

• Palette contents must be known & defined upfront,
• by someone able to develop Eclipse plugins,
• that must be built and then installed in the (RCP) application,
• which even requires a restart to activate the changes/additions.

But this approach does not fit the requirements for CapeCode where actor library configurations are managed in JSON files, hosted on remote locations. We don't want to replicate such configurations in plugin.xml files, nor having to go through complete development/build/install cycles to add or maintain CapeCode libraries.

So an alternative mechanism to add palette contributions has been put in place, based on OSGi services, to combine the possibility to reuse CapeCode's existing library definition files with dynamic loading behaviour.

The service interface is defined as follows (in org.eclipse.triquetrum.workflow.editor.palette.spi):

 public interface PaletteEntryProvider {
   /**
    *
    * @return the palette entries from this provider, as configuration elements
    */
   IConfigurationElement[] getPaletteEntries();
 }

org.eclipse.triquetrum.workflow.editor.palette.spi.PaletteConfigurationElement is a plain implementation of IConfigurationElement that provides all properties of palette entries to match the features that are also supported in the extension point schema.

To load an accessor library, the provider interface can be implemented based on CapeCode's org.terraswarm.accessor.AccessorLibrary.