Differences between revisions 9 and 13 (spanning 4 versions)
← Revision 9 as of 2007-11-29 19:46:32 →
Size: 575
Editor: pix39
Comment:
← Revision 13 as of 2008-02-01 19:29:48 →
Size: 3205
Editor: nebbiolo
Comment:
Deletions are marked like this. Additions are marked like this.
Line 3: Line 3:
= Release 3.0 Use Cases / Overall Themes =
(Under construction) 		= 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.
Line 6: Line 11:
= Rearchitecture Discussions =
[:Oct2007SeattleMeeting: Seattle Meeting 2007] 		= 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].
Line 9: Line 21:
[:CytoscapeRetreat2007/HackathonNotes: Amsterdam Hackathon 2007] = Discussions =
 * [:Oct2007SeattleMeeting: Seattle Meeting 2007]
 * [:CytoscapeRetreat2007/HackathonNotes: Amsterdam Hackathon 2007]
 * [:Cytoscape_3.0/Model: New Model]
 * [:Cytoscape_3.0/View: New View Structure]
 * [:Cytoscape_3.0/HyperEdges: Hyperedges]
 * [:MavenInfo: Some info for using Maven]
Line 13: Line 31:

= Release 3.0 Feature Ideas (VERY tentative) =
== New Features ==
 * Better modulality - OSGI model?
 * Multi-thleading - better support for multi-core/CPU machines.
    * Layout Algorithms
    * Analysis tools
 * [:Cytoscape_3.0/Model: New Model]
 * [:MavenInfo: Some info for using Maven]

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].

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