Scripting

Note: Experimental scripting plugin is available now. Currently supports Ruby only. For more information, please visit ScriptingPlugins.

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

Proposal

Implementing scripting (Python, Ruby, Java Script, etc.) functionality for Cytoscape. Scripting languages provide an alternative interface to Cytoscape functionality. By providing scripting support we will enable more users to take advantage of Cytoscape in new ways. There are two alternative scenarios to consider:

1. Start cytoscape normally and then load a script to execute.
2. Run a script normally within the operating system that then starts cytoscape or uses cytoscape functionality.

Biological Questions / Use Cases

1. Apply the same operation to a large number of networks/files. Often users want to perform the same set of operations on a large number of networks. Scripting this sort of task is an obvious solution to reducing redundant work.

Open Issues

• The Cytoscape interface is currently WIDE open, meaning any plugin can call any public method. This causes all manner of problems and by providing the same access for scripts, we will be exacerbating the problem.

• Headless mode. A lot of processing and network analysis makes more sense without using the GUI. Currently Cytoscape doesn't have proper support for headless mode. See the HeadlessModeRFC.

• This is also closely related to the CodeLayering RFC.

Implementation Plan

Java provides support for running scripting languages from within the Java Virtual Machine using the Bean Scripting Framework. Using this framework, access to the following scripting languages:

• Javascript

• NetRexx (an extension of the IBM REXX scripting language in Java)

• Python
• Tcl
• XSLT Stylesheets
• Groovy
• JLog (PROLOG implemented in Java)
• Ruby

• JudoScript

• ObjectScript

• ooRexx (Open Object Rexx), using BSF4Rexx.

One possible implementation strategy would be to add the Bean Scripting Framework functionality to the core and then provide plugins for each scripting language. For instance, if a user was interested in writing a Python script to perform some task in Cytoscape, the user would first load the Python scripting plugin. Then the user would be able to load and execute scripts from the (as yet undefined) scripting user interface. This would allow users to load only the scripting languages they choose and help avoid (excessive) bloat.

Comments

July 24, 2007: ScooterMorris

I think that adding a full scripting language such as Javascript or Ruby is a great idea, but I also think we need a simpler command-oriented interface. This might not apply to Cytoscape users, but at least for Chimera, our users sort of divide into three camps:

1. Users who only use the interface
2. Users who are comfortable with programming and will gladly utilize Chimera's Python interface capabilities.
3. Users who use Chimera's command-line interface to create command files that can be executed and shared

I suspect that this taxonomy could be applied to Cytoscape users also (except that there is no command line). I think we should pursue scripting for both user groups 2 and 3 above. This would mean that we would integrate a scripting interface for more accomplished programmers who are familiar with the object-oriented paradigm and are willing to learn some of the basic Cytoscape classes -- we would also want to create a command-line interface that would be much more restrictive, but would provide a simple way to execute the basic Cytoscape functionality. I don't see these as mutually exclusive at all, in fact, I think they can be quite complimentary.

I do have some concerns about releasing a scripting language in 2.6, however. As pointed out above, the implementations would necessarily expose the Cytoscape public APIs and object hierarchies. I think that releasing a scripting interface publicly would be much better after we complete some code layering -- perhaps hiding the giny interfaces entirely and only exposing Cytoscape objects: CyNetwork, CyNetworkView, CyNode, CyNodeView, CyEdge, and CyEdgeView or something like that.

July 26, 2007: Kei Ono

How about release this function as an experimental feature for programmers? Basically, it is an alternative to write a plugin. I know many users who do not want to write build.xml and java classes, but willing to write 20-lines sctipts.

We will not guarantee the script written for 2.6 work in the future releases, but still it is a nice tool for doing small tasks.

Aug 8, 2007: MikeSmoot

I wonder if we could implement a command language that would be available on the command line like the java -X options, which is to say that one flag can be used for many different options?

I'd want and "commands" to be well integrated with the rest of cytoscape, which is to say that a "layout network" command should call the same code that gets called when a layout is selected from the GUI. CytoscapeAction seems like the obvious place for this.

Aug 20, 2007: Corwin Joy

The idea of scripting for Cytoscape is a good one. It seems that some work has already been done in this area to script Cytoscape from R via the CytoScript project. (http://metnetdb.org/fcmodeler/cytoscape/CytoScript.pdf). Perhaps this has some ideas we can re-use?