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 will 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
    • Suggestion for controller/command/action layer -allows scripting, workflow, history, etc.
  • Model

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

    • Where does node x,y go? 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
    • Vizmapper UI goes in the application layer, mapping API is in view layer
    • XGMML IO contains model and view information, so IO is dependent on view

    • 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
      • 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
    • Loading of model and view information