RFC Name : Cytoscape Plugin Bundles

Editor(s): Alex Pico and Sarah Killcoyne

Status: Open for Comment

<<TableOfContents: execution failed [Argument "maxdepth" must be an integer value, not "[2]"] (see also the log)>>

Background

Cytoscape’s flexibility and utility comes from its plugin architecture. Community-developed functionality allows Cytoscape to continually evolve and meet diverse needs. There is current work to improve the architecture for plugin development (see RFC 46 and RFC 47), as well as to improve plugin distribution by means of a Plugin Manager (featured in v2.5; also see RFC 27). Providing categorized lists of plugins helps users access and install the functions they need. However, more work needs to be done here to assist users in identifying which plugins are relevant to their data and research goals.

Proposal

Building upon the function of the Plugin Manager, this proposal aims to provide users with organized plugin bundles. These bundled sets of plugins could then be installed together to essentially produce a themed version of Cytoscape, tailored for specific tasks (see Theme Ideas below). We are continually identifying particular use cases for Cytoscape and associated sets of plugins. By introducing the concept of ‘themes’ into the Plugin Manager, we will make it easier for users to identify the plugins they need to accomplish their particular research goals using Cytoscape.

Changes to Plugin Manager

ThemesRFC_mockUI_v2.gif

User Interface

Currently, plugins are organized by arbitrary categories within two top-level folders: ‘Currently Installed’ and ‘Available for Install’. Here is one way we could integrate bundles into the Plugin Manager UI:

  1. A folder called “Themed Plugin Bundles” could be listed at the same level as the current categories (see figure above). Expanding the folder would display the bundle names and versions (analogous to individual plugins listed under a category). Selecting a bundle would display information about the bundle and the plugins included using the display on the right.
  2. Installing a bundle would force the installation of all the plugins in the set. This provides a way to handle intentional plugin-plugin dependencies within a given bundle.
  3. When a bundle is installed, it would show up in the Bundles folder under ‘Currently Installed’, just like with plugins in the current categories.

Saving Plugin Bundles

Bundled plugins could essentially be saved using the same mechanism already in place for Plugin Manager for saving individually installed plugins. However, the manager would have to be able to distinguish between plugins that could be independently installed and uninstalled versus plugins that can ONLY be installed and uninstalled as part of a bundle (i.e., when dependencies are an issue). The information about which plugins should be installed via the Plugin Manager should be able to be easily shared or even pre-packaged to induce similar plugin loading across Cytoscape installations. This way you can distribute Themed versions of Cytoscape with users who might not be comfortable or have the time/patience to configure plugins.

Prompting to Load Saved Bundles

There could be a prompt verifying that you would like to load a saved plugin bundle. This way you could opt out for a given session, but still retain the option next time you run. Perhaps you could even save multiple bundles and choose which one to load per Cytoscape startup. You can see how this is approaching a full blown ‘Welcome’ screen used by many advanced applications to help the user navigate preferences and perspectives at startup.

Adding Vizmap.props (“props” go to Scooter for this idea)

Taking the idea of bundles one step further, you could imagine bundling a vizmap.props file along with particular sets of plugins to give users the most intuitive and informative visualization of their network in the context of the type of analysis enabled by the plugin set. Bundles could potentially include data files or other props files required by a plugin, however to work with the Plugin Manager a plugin in the bundle needs to load these files on it’s own. They won’t be installed in the main cytoscape directory but in the .cytoscape/<version> directory instead.

Theme Ideas

  1. Nature Protocol Plugins: an obvious set of plugins for a focused task. Having bundles will make it very easy to direct users to specific plugin sets.

  2. GenMAPP-CS: someday we’d like to distribute GenMAPP-CS as a packaged theme of Cytoscape with a set of plugins that not only provide GenMAPP-like functionality, but also control major aspects of the user interface, simplifying menus, window layout, and features.

  3. Structure-Function Bundle: Scooter?

  4. Bundles derived from Allan’s recent Cytoscape use case query?

  5. See CytoscapeThemes RFC for more details of component plugins that add a little syntactic sugar

Development Timeline

For 2.6

Extra credit for 2.6

Beyond 2.6

Implementation Plan

plugin.xml Changes

A new section will be added to the plugin.xml file describing a bundle and where to access the correct plugins. Similarly to a single plugin the bundle will need to have a unique ID to make updating possible, name, description, bundle version and cytoscape version. It will then list the plugins by unique ID and version. For now it will be assumed that the plugins are at the same download location as the plugin.xml file. This could be generalized in the future to allow plugins from other servers to be downloaded in a bundle. 

<!-- From the test_plugin.xml in testData/plugins -->

<project>
  <name> Cytoscape Plugins </name>
  <description> Test </description>
  <url> http://cytoscape.org </url>

  <pluginlist>                          
    ...
  </pluginlist>

  <themes>
    <theme>
      <uniqueID> </uniqueID>
      <name> </name>
      <description> </description>
      <themeVersion> </themeVersion>
      <cytoscapeVersions> 
        <version> </version>
      </cytoscapeVersions>
      
      <pluginList>
        <plugin>
          <uniqueID> </uniqueID>
          <pluginVersion> </pluginVersion>
        </plugin>
        <plugin>
          <uniqueID> </uniqueID>
          <pluginVersion> </pluginVersion>
        </plugin>
      </pluginList>
    </theme>

    <theme>
      ...
    </theme>
  </themes>

</project>

Similar changes will be made in the .cytoscape/<version>/track_plugins.xml file.

Code Changes

  1. Classes involved in reading and writing the xml files will be changed to read themes (PluginTracker.java, PluginFileReader.java).

  2. Create an interface for downloadable objects (DownloadableInfo)

  3. New info object will be created simlarl to PluginInfo (probably ThemeInfo). These two objects have slightly different requirements, but contain a lot of the same information. Both will implmement the downloadable interface.

  4. Changes will be made to the PluginManager to recognize themes and install/delete all plugins from a theme together.

  5. Minor UI changes to the Plugin Manager/Updater windows to show themes.

Comments

AllanK

Since I am on tap for doing a Workflow Panel for Cytoscape 2.6, I would like to coordinate my efforts with yours. I have a couple of points and questions:

  1. The workflow panel should be able to check programmatically that all the appropriate plugins are installed and probably grey out the possible selections for those that aren't. What's the best way to do this? Should the Workflow Panel check for each plugin individually? Or should we generate the Workflow Panel from the theme, thus implying that the theme is installed?
  2. The main distinction of a workflow panel, as an interface to a theme, is that the items in the workflow panel are ordered? Is there a way that a theme can optionally specify an ordering for its elements?One other point: Should a theme include elements of Cytoscape that are not in plugins but in the core? Certainly a workflow should. Should such core elements be specified as part of the theme, even though they don't need to be installed?

Alex

We should have each workflow plugin be part of a theme so that all the appropriate plugins are loaded along with the workflow. This is a great example of using themes to handle plugin dependencies.

SarahKillcoyne

9/19/07

I agree with Alex about the workflow plugin. I think it's a perfect use of the themes. Couple of questions about how people think themes should be handled with users in the basic case (what will be done for 2.6):

  1. If a theme contains a different version of a plugin already installed this could cause an issue for the theme.
    • My thought is to warn the user and ask if they wish to overwrite or keep the existing plugin, with the understanding that it might not work.
  2. Should the Plugin Manager track installed themes separately from individual plugins? Meaning that a user could choose to delete an entire theme but not a single plugin within a theme.
    • I tend to think this is the right way to go, if we're using themes in part to handle plugin dependencies, allowing a user to delete single plugins would defeat the purpose. This also means plugins within a theme are not updatable singly, the entire theme would need to be updated.

AllanK

I agree. Themes should be indivisible.

How to Comment

Edit the page and add your comments under the provided header. By adding your ideas to the Wiki directly, we can more easily organize everyone's ideas, and keep clear records. Be sure to include today's date and your name for each comment. Try to keep your comments as concrete and constructive as possible. For example, if you find a part of the RFC makes no sense, please say so, but don't stop there. Take the extra step and propose alternatives.

CytoscapePluginBundles (last edited 2009-02-12 01:03:29 by localhost)

MoinMoin Appliance - Powered by TurnKey Linux