Cytoscape Wiki|
Size: 1702
Comment:
|
Size: 5194
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 13: | Line 13: |
| Implementing scripting functionality for Cytoscape. This is for both support for general scripting language (Python, Ruby, Java Script, etc.) and Cytoscape specific simple scripting. |
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. 1. Run a script normally within the operating system that then starts cytoscape or uses cytoscape functionality. |
| Line 17: | Line 21: |
|
== General Notes == == Requirements == == Deferred Items == |
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. |
| Line 25: | Line 25: |
| == Backward Compatibility == |
* 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. |
| Line 27: | Line 29: |
|
== Expected growth and plan for growth == == References == |
|
| Line 33: | Line 31: |
| ##If you want to create a separate subpage for the Implementation Plan, then provide this link: ["/Implementation Plan"] |
Java provides support for running scripting languages from within the Java Virtual Machine using the [http://jakarta.apache.org/bsf/ 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 [http://jakarta.apache.org/bsf/ 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. |
| Line 37: | Line 49: |
|
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. |
|
| Line 38: | Line 66: |
|
=== 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.''' |
RFC Name : Scripting in Cytoscape |
Editor(s): Keiichiro Ono |
Status: Open for Comments |
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:
- Start cytoscape normally and then load a script to execute.
- Run a script normally within the operating system that then starts cytoscape or uses cytoscape functionality.
Biological Questions / Use Cases
- 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 [http://jakarta.apache.org/bsf/ 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
- ooRexx (Open Object Rexx), using BSF4Rexx.
One possible implementation strategy would be to add the [http://jakarta.apache.org/bsf/ 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:
- Users who only use the interface
- Users who are comfortable with programming and will gladly utilize Chimera's Python interface capabilities.
- 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.