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
    • 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 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 planning

• Resources:
  • UCSD/Unilever: Mike 1.0, Kei .25, Peng .25

  • UCSF: Scooter 0.5, GenMapp group 1.0

  • ISB: Sarah 1.0
  • Unilever: Noel .25
  • HSC: Brian .25
  • AMC: Piet .25
  • Pasteur: future hire 1.0
• Commitment: functional prototype by next retreat, summer 2008. Participate cytostaff mailing list and weekly conference call

3.0 break out sessions

• 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