CytoscapeRewrite

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

Proposal

Many Cytoscape clones are available that: utilize both web and server based technologies; use advanced information visualizations of graphs; and support a plugin architecture. While Cytoscape is still used preferentially, we can improve the functionality in a number of ways, including: clear scripting/macro capability; web based delivery; allowing for high throughput asynchronous message based analysis; server/distributed functionality; uniform access to data sources; and a componentized code base (e.g. to change the rendering code). In order to undertake this effectively there are two possible strategies, code refactor or code rewrite.

A refactor (See RFC 46) will take our current code base and reorganize it, giving us some opportunity to rework parts like the event handling but leaving us with essentially the same code we have now. If we consider a rewrite two strategies are available. Either we keep the current overriding architecture and develop a fat client or we move towards an alternative, thin client architecture. This would be a fundamental change in our code, but it would also move Cytoscape towards a modern, componentized architecture with the potential of being expanded easily into an enterprise system.

Either the fat or thin client architecture would allow us to separate the functionality cleanly for a more flexible and maintainable code base while easily adding more powerful functionality such as: a command layer for scripting and macros; a project based system; and full unit testing. This proposal builds upon the following RFCs: (38) Code Layering, (40) Scripting in Cytoscape, (6) Cytoscape Headless Mode Operation and (46) Cytoscape Relayering.

Use Cases

See Use Cases in RFC 46. Use cases specific to a rewrite:

• Faster to rewrite. In the 5 years that Cytoscape has been in development most of the issues relating to the core features will have been dealt with. Using what has been learned and potentially code currently in Cytoscape that has been well architected a rewrite will actually be faster because the developers won’t be tied to using old interfaces or spaghetti code that has been tacked on in the process of deprecating old code.
• Plugin rearchitecting can begin as soon as the basic model and IO layers are in place and continue throughout the process of writing view and application instead of having to wait (in the relayering RFC plugin rearchitecting cannot begin until the first fully relayered system is in place)
• A new project based system can be planned and implemented cleanly without requiring old code to be refactored.
• Tools that are integral and important to any basic network application such as search, filter, analysis and statistics can be added, drawing from work already done in core plugins.
• Full unit and deployment testing can be easily added to the build process as part of a rewrite making future feature addition simpler, cleaner and easily testable

Implementation Plan

Build Dependencies

The proposal is to initially introduce four layers into the code: Model layer which contains the business logic; View layer containing all the graphical/presentation code; IO layer which controls readers/writers; and the Application layer containing all of the GUI systems such as menus, windowing and VizMapper.

Option 1: Fat Client Architecture

Package Structure Overview

The package structure would be as described in RFC 46 with the exception that a Commons package for temporary interfaces would not be required.

Project Management

Project Plan

Tasks & Milestones

1. Milestone 1 - Prototype: FTE 1, 2, 3 - 4 weeks

   1. Specifications gathered and written b. Prototype written with package structure in place and basic views

2. Milestone 2 - Model & I/O Package: FTE 1, 2, 3 - 8 weeks

   1. Model package including model events b. I/O package

3. Milestone 3 - View: FTE 1, 2, 3 - 16 weeks

   1. Macro & Micro views take 8 - 16 weeks depending on decisions made about renderer (rewrite, use as is with interface updates or find 3rd party renderer) FTE 1, 3 b. Project System view - 8 weeks. Depends on specification gathering and prototyping as this is a new feature. FTE 2 c. Annotation view - 8 weeks. FTE 3

4. Milestone 4 - Application: FTE 1 - 16 weeks. Much of this should be easily portable from current Cytoscape application such as the VizMapper and current core plugins.

   • Menus (new menu bar)
     • File
     • Edit
     • Window
     • Tools
     • Plugins
     • Help
   • Tools
     • Search
     • Analysis
     • Statistics
     • Layouts
     • Editor
   • Window layouts
     • Tiled, cascaded, etc

   • VizMapper

   • Clipboard operations
     • Copy, cut, paste
   • Drag/Drop

A 4th FTE could be added for the following tasks:

• Unit/Deployment Tests and documentation, 12 - 16 weeks
• Command layer (allowing for scripting, macros, “headless” Cytoscape), 12 weeks

Issues

See Issues in RFC 46

Option 2: Thin Client Architecture

Package Structure Overview

The layers of a thin client would be similar to those of the fat client architecture, but would be split further.

The application server (Tomcat) would contain the API’s for the Model, IO and perhaps the View. Plugins would be able to work as servlets (pushing their data to both the Desktop or Browser versions) or as part of the Desktop application in a jar file similar to their current installation. This structure would take care a several current issues through the application server, including messaging, resource management and exception handling (negating the need for several current RFC’s). It would also give us the ability to run Cytoscape as enterprise software for an entire institution using clusters for more computing power and private, local databases in addition to external data sources or continue to run as an individual desktop application similar to the Gene Pattern software developed by the Broad Institute at MIT.

Project Management

Project Plan

Tasks & Milestones

1. Milestone 1 - Prototype: FTE 1, 2, 3 - 4 weeks

   1. Specifications gathered and written b. Prototype written with package structure in place and basic views through Tomcat

2. Milestone 2 - Model & I/O Package: FTE 1, 2, 3 - 8 weeks

   1. Model package interface exposed through Tomcat b. I/O package interface exposed through Tomcat

3. Milestone 3 - View: FTE 1, 2, 3 - 16 weeks

   1. Macro & Micro views - 8 weeks FTE 1, 3 b. Project System view - 8 weeks. Depends on specification gathering and prototyping as this is a new feature. FTE 2 c. Annotation view - 8 weeks. FTE 3

4. Milestone 4a - Desktop Application: FTE 1 - 9 weeks. Much of this should be easily portable from current Cytoscape application such as the VizMapper and current core plugins.

   • Menus (new menu bar)
   • Tools

   • VizMapper

   • Clipboard operations
   • Copy, cut, paste
   • Drag/Drop

5. Milestone 4b - Browser Application: FTE 1, 3 - 8 weeks. This milestone is optional for the actual release version of Cytoscape via a distributed platform. It can be done at a later date.

   1. Prototype - 4 weeks b. Release version supporting basic Cytoscape functionality 4-8 weeks depending on technologies chosen (SVG, Ajax, Google Maps, etc)

6. Milestone 5 - Installation Wizard: FTE 2 - 2 weeks

   1. Bundle the application server (Tomcat) with the Cytoscape interfaces b. Create run/stop scripts for the Cytoscape server

Optionally a 4th FTE could be added to do the following:

• Unit/Deployment Tests and documentation, 12 - 16 weeks
• Command layer (allowing for scripting, macros, “headless” Cytoscape), 12 weeks

Issues

• See Issues in RFC 46 - Cytoscape Relayering
• There would be some infrastructure overhead and some changes in the development process

Comments

Please include your name and the date of the comment to help keep comments organized