Day 1 notes

Session 1: Cytoscape 2.6/2.7

Decisions:

• Cytoscape release: Mid Jan, Feb.1 as goal for release
• Testing as a task – assign different parts of Cytoscape to developers for testing - offline. How can we get more developers and users involved in testing.
• No 2.7 will be released (decision could be revisited), but we will work on 2.6 and add documentation, bug fixes, small features, new core plugins in maintenance releases. Goal: smooth over most of the workflows.

Discussion threads:

• Introductions (everyone)
• Cytoscape 2.6 development status update
• Testing - how to increase coverage and get better unit tests
• Should we have a 2.7 release?
• Plugin developers have issues with too frequent releases
• Feature suggestion from Carlo: action tracing - how did I get to this result?
• Smoothing workflows may take a while to do
• Break

Session 2: Cytoscape 3.0

• 3.0 overview
• Cytoscape problems - things that the RFCs address
• People would like to have a stable plugin API and also access to internal classes
• Going through all of the RFCs
  • Line types - can't we support some extra custom line types for 2.6.x? No, the renderer doesn't support some line types. It would need low level changes.

• RFC 52: Event Handling System

  • Mouse events are clobbered - major issue is that multiple plugins want to access mouse related events. This could be solved by having Cytoscape mediate the events. There may be a use case for plugins to only listen to events for specific networks e.g. for networks they create. Events could be modeled based on user intention e.g. instead of mouse click, say select node. This would allow e.g. shortcut keys to be remapped and would make it easier for actions to be associated with specific shortcuts.
    • Decision: Only allow plugins to listen to Cytoscape events, not lower level events, to allow arbitration, prevent conflicts.
    • Decision: A module should define its event interface - the events it listens for and produces
    • Decision: Plugin registers interest in specific events within the scope of user edits with some manager system.
    • Task: event inventory
    • Task: what events do we need?

• OSGi intro - OSGi is a module strategy above packages. Jars list public and required classes in manifest (a bundle). Cytoscape could use this to make available e.g. CyNode. OSGi also allows service definition and provides a registry. OSGI_Refactoring_Possibilities

  • alternatives are Raven, new things coming along in Java 7, netbeans
  • Should we use eclipse to prevent writing things like key mapping and many other things
• Lunch

Session 3: Cytoscape 3.0 (cont)

• rewrite vs. refactor
• Should plugin developers wait to work on plugins until 3.0 comes out? No, since 3.0 is at least 18 months away. To help this, we can release the 3.0 APIs early (maybe in a 2.7 release)

• RFC 46: Cytoscape Layers Refactor

  • Model, view, application, IO
    • Decision: controller/command/action layer -allows scripting, workflow, history, etc.
  • Model

    • Decision: What is in the model? Network: CyNode, CyEdge, CyNetwork, CyGroups; Attributes: CyAttributes

    • Where does node x,y go? Decision: They go in view, but need to be in the view.model. You would have a separate view implementation for headless mode that allows you to manipulate x,y without a rendering.
    • View is one of many views of the model e.g. rendered 2D view, headless 2D view, 3d view
    • Decision: Vizmapper UI goes in the application layer, mapping API is in view layer
    • Note: XGMML IO contains model and view information, so IO is dependent on view

    • Decision: CyAttributes needs some utility methods for helping choose types when accessing data

    • Should attributes be part of the node? "I want to ask a node for its attributes"
      • Rationale for this question is the use case for attributes to be linked to a node so when the node goes away, so do the attributes. Maybe this could be dealt with with the hidden/locked flags of attributes
      • Decision: Attributes should be a 1st class citizen since Cytoscape is a data integration platform that integrates attributes, entities and their relationships.
      • This discussion highlights many features that would be nice to have related to viewing attributes e.g. attribute metadata (which can be handled with the multihashmap) or general spreadsheet functionality.
      • Another problem is that attributes lose their order when loaded, which is annoying with time series microarray data.
  • View
    • Need to have multiple views of the model
  • IO
    • Decision: Loading of model and view information
• break

Session 4: Cytoscape 3.0 (cont)

• RFC 47: Plugin Interface Refactor

  • What is the minimal functionality that Cytoscape provides
    • one answer: all the model APIs
  • What should be excluded? All the implementations.
  • Should we provide backdoors in APIs e.g. setObject, getObject?
  • Provide best practices for plugin interoperability. Internals would be available for people to use, but wouldn't get the benefits of backwards compatibility - you could pick what bundles you need from Cytoscape and build it up yourself if you want.

  • Resource management: prevent plugins using up all resources - need a stable API for this. E.g. database pooling. Like Firefox, community can rank and rate plugins to help users choose plugins that play nice.

  • Look into Java delegates in place of AOP? AOP is problematic to debug and extend. E.g. for logging.
  • Capturing plugin types from a CV e.g. Taverna has a model for this - source code annotations (beans for description, factories to create the beans, but also factories that talk to a web service to populate the beans with info about a service)

• RFC 51: Cytoscape Projects

  • Projects: include plugins, workflow, data, themes
  • Should be able to load (or appear to load, ie the tree of projects can show all the available projects but only open one at a time) multiple projects

• Workflow:

  • Would be nice to record the actions you use for new workflows
  • jABC demo e.g. of workflows
  • ID mapping - mapping attributes to nodes as another part of the standard load, analyze, view, publish workflow - part of integration

• Controller/command layer

  • Do we want to have both setters and actions, since interleaved use could ruin undo/redo?
  • Actions, supporting scripting, documentation, visual workflow definition use case, threading, undo/redo, ability to be set on a thread, task monitorable, use case: action history, recording macros, use case: use matlab or R to control Cytoscape
  • Tunables to generalize the parameters to actions, or getter/setter with annotation and introspection

Day 2 notes - planning

• Board approval for 3.0 development. Yes, but we need to adopt a 'no plugin left behind' policy, or some approximation of it.
• Long lived 2.x branch to support existing plugins while 3.x matures
• Transitional API for old plugins in 3.0
• Development team helps with porting plugins to 3.0. We can prioritize them based on use.
• Plugin developer preference: Move everyone over once to 3.0 - clean break
• Release interfaces early for 3.0 for plugin developers for their review
• Provide clear instructions on how to upgrade and sample code + full developer tutorial.
• Propose 3.0 plans to community for input, proactive communication to existing plugin developers. Clarify expectations on both sides. Opportunity to involve plugin developers more and ask if they want to include their plugins in the core, move their plugin code to core SVN (communicate advantages to them). Core ends up being the set of packages that get downloaded, but additional packages are available from a central location. Plugins in SVN will help fix key plugins more easily. Adding the plugins to the testing schedule. Engage plugin developers. Mechanism for call for help for plugin upgrade.
• Creation of a plugin commons e.g. in Google code that allow everyone to contribute code more easily.
• Existing Cytoscape version 2.6 will always be there for use.
• Decision: Move to 3.0, do a lot of work to support plugin developers.

3.0 break out sessions

• Had 2 groups break out and discuss the refactor layers
• One group later discussed what plugin developers would like from a refactor
• Refactoring team - 6 month commitment
  • View, Model, IO, Controller, Application
• Plugin migration team - one year part time commitment (Mike)
  • Migration assistant tester, plugin maintenance FTEs (make sure important plugins are ready for 3.0 release), interface definitions

Layers for discussion

Refactor Group 1 Notes

Included: Scooter, Mike, John, Alex...

(to be filled in)

Refactor Group 2 Notes

Included: Allan, Gary, Ilya, Sarah, Benno...

Model Layer

• Network
  • - The group felt that mixed directed/undirected graphs did not need supporting, but in further discussion there may be use cases to for mixed graphs. - Did not discuss "what is a network?"
• Node
• Edge
• Attribute
  • - Needs roles (mutable, hidden, etc.), ordering, grouping and metadata (perhaps as a different data type that can be attached to any model object, 'annotation' or something) - Felt that we should start supporting just local attributes for each type (Network specific Node/Edge attributes) taking care of both namespacing and removing attributes when their associated model object is removed.
• Project

• NodeGroup

  • - These are hierarchical so fairly different from the HyperEdge but there may be some basic concept that links them, requires further discussion.

• HyperEdge

  • - Needs further discussion, basic thought is that this is not how a default edge is created but is available as a model data object for advanced usage.

• ModelList

  • - Could contain a list of any model object.

Command Layer

This layer has some basic properties:

• Atomic transactions
• Contains only actions to be done on other layers

• Handles threading of an action and events, all actions would have start and end events

• Would be undoable and redoable

View Layer

This is not the presentation layer in that it contains no actual gui type presentation logic but is instead an abstract layer to handle all data associated (such as color mapping, coordinates, etc). Might help to rename this layer for clarity (ideas?). Few things that came up for the view layer to handle:

• Controlling node and edge view, basic use case: Duplicating nodes in a view (such as H20) without showing all possible edges for each duplicated view of a node.
• Needs to have a basic view object that could be extended/implemented for any other view to contain coordinate type information (x, y, z, t) for use in "headless" mode.

Application Layer

• Contains GUI stuff: menus, toolbars, canvas etc
• Would be nice to set up the layer such that the basic canvas can be easily embedded inside other applications
• Should set up toolbars. The basic default toolbar should have access to layouts, search and filters. Plugins should have access to add to a toolbar
• Should set up a toolbar that is user-configurable as well

Plugin Developer Requests Group

These requests were gathered from plugin developers in a separate session on day 2. These are not necessarily comprehnsive and discussions should continue with plugin developers throughout the process.

Required functionality

1. Graphics Access: In any refactored system access to raw drawing privatives (e.g. java 2D functions on the canvas) is required. This is for advanced graphics plugins.

2. MDI operations: Control of position, and other layout properties for windows, through hints or similiar is desirable.

3. Resource management: The use of a threading resource management system could be adopted. However, connection resource management is more specific to particular data sources and so was not felt to be practical.

Documentation and Specification

1. Tutorials: Whilst documentation is important, tutorials and examples would also be required. The example plugins should not be of the “hello world” variety, but should consist of a hierarchy of the most common types of plugins (e.g. layout plugin example). These would, obviously, have to be maintained.

2. Interfaces for plugin definitions: It was felt that, due to the multi faceted nature of plugins plugins, it would be difficult to describe just using a standard set of interfaces. Although in some cases such a role/functional description could be used.

3. Development tools: Extensible plugin build and test files (through ant, maven or similar) is desired.

Other Issues

• Plugin API testing: Five plugin developers offered to help test beta releases of the new plugin API (names not put on the wiki)

3.0 planning

Plans & Milestones

The following plans/milestones were agreed to at the end of the day on Friday. Mike Smoot will act as a coordinator and hand out tasks to the developers who signed up (listed below). All have agreed on the timeline and will continue to use the cytostaff list and wiki to help communicate.

Phase I

Milestone 1: Model Layer Specification. Due: End of January 2008

• Via mailing list and wiki (RFC's) the developers will agree on specifications for new Model object layer and the interfaces

Milestone 2: Functional modular build with unit tests. Due: 2 month post 2.6 release (roughly end of March 2008)

• Package Definitions
• Simplified interfaces
• Actions separation

Phase II (filled in further post PI/Milestone 1)

Milestone: Implementable model, working prototype Due: July 2008

Developer FTE's for 6 months

MoinMoin Appliance - Powered by TurnKey Linux