Differences between revisions 14 and 15
Revision 14 as of 2008-02-07 17:57:06
Size: 3206
Editor: pix39
Comment:
Revision 15 as of 2008-04-03 16:31:22
Size: 3275
Editor: GaryBader
Comment:
Deletions are marked like this. Additions are marked like this.
Line 21: Line 21:
= Refactoring Strategy =


= Rough module refactoring plan =

TableOfContents

Release 3.0 Overall Goals

There are several motivations for release 3.0 of Cytoscape, but the overriding theme of the release is to refactor/redesign the code so that things become easier. Things in this case has several specific meanings:

  • Easier interface for plugin writers to understand and use.

  • Better modularity or layering making it easier for components of Cytoscape can be used in different contexts.

  • Clean up/refactor the structure of the existing Cytoscape core so that it can be more easily maintained, modified, and extended in the future.

  • Make backwards compatibility easier to maintain.

  • Clean up the user interface so that it's easier for users.

Desired Features

  • 2.6. The primary feature for Cytoscape 3.0 is to do everything that 2.6 does. See [http://cytoscape.org Cytoscape].

  • Layer Cytoscape. Separate Cytoscape functionality into clearly defined layers or modules. The motivation is to allow alternative users of Cytoscape. For more information read: [:CytoscapeLayerRefactor: RFC 46], [:HeadlessModeRFC:RFC 6], [:WebFrontEnd: RFC 55].

  • Separate the view from the model. The motivation for this is to use Cytoscape in various headless (or alternatively headed) modes. See: [:HeadlessModeRFC:RFC 6], [:WebFrontEnd: RFC 55].

  • Command layer. In current versions of cytoscape one of the primary impediments to headless mode operation is the problem that the GUI it tightly coupled with almost all actions available to users (load file, save file, etc.). To solve this, Cytoscape needs a command layer that is cleanly separated from the application (not necessarily the view). This command layer should also be extensible so that plugin writers can add their own commands. See: (write an RFC).

  • Improved Event handling. Cytoscape currently uses a mish-mash of different events to signal system state changes. This is confusing, error prone, and causes performance problems. We need to develop a simple, clean Cytoscape event handling interface that can be used listen for and fire common events. See: [:EventHandling: RFC 52].

  • Custom graphics. We would like the ability for plugin writers to be able to define their own shapes and edges to be displayed and integrated into Cytoscape. See: [:RichLineTypes:RFC 32], and (write shape RFC).

  • Improve build process and package structure. We would like to simplify the build process for cytoscape so that all necessary libraries and plugins can easily be found and built with the core. See: [:DependencyManagement:RFC 44].

  • Local Attributes. Allow for attributes to be specific to networks in addition to maintaining the current global attributes. See: [:LocalAttributes:RFC 31], [:AttributeNamespaces:RFC 37].

Refactoring Strategy

Rough module refactoring plan

Discussions

Timeline

Release Date: TBD

Outdated_Cytoscape_3.0 (last edited 2011-12-01 18:04:03 by server2)

Funding for Cytoscape is provided by a federal grant from the U.S. National Institute of General Medical Sciences (NIGMS) of the Na tional Institutes of Health (NIH) under award number GM070743-01. Corporate funding is provided through a contract from Unilever PLC.

MoinMoin Appliance - Powered by TurnKey Linux