Core Cytoscape Feature Prioritization
Date: Saturday, July 19, 2008
Description
Detailed list of tasks to push ahead with OSGi adoption and assessment. Names and estimated deadlines included.
Tasks
- build system - easy to use for plugin developers (Kei - end of Aug)
- setup repository
- documentation on wiki for a naive developer
- maven site documentation
- debugging in eclipse (other IDEs) must be easy for plugin developers (ISB - end of Aug)
- testing of core and plugin development process by core and naive developers (AlexP, Allan, Scooter, Mr.X - mid Sept)
test web start (see http://help.eclipse.org/help32/index.jsp?topic=/org.eclipse.platform.doc.isv/guide/java_web_start.htm)
- develop templates/demos for plugin interoperability, dependency, extension, multiple versions coexisting, etc.
- Cytoscape Presence (ISB + AlexP, Kristina - December?)
- collect materials: video ideas, tutorials, course material, selected publications (scivee?)
- build, identify infrastructure for this material
- deploy
- discuss consistency/style guidelines
- Cleaning up all warnings and mvn find bugs (Everyone!)
- a lot of these are unchecked errors
- site hackathon?
- split up arbitrarily
GraphPerspective <-- new CyNetwork (Mike -> Everyone!)
implications for CyNodeAttributes, CyEdgeAttributes
work out details for selection, hide=>remove; this has implications in other places that relied on "hide"
- this directly addresses the new "copy model" versus root graph model
this is not a simple find/replace
- Mike can do some initial work on it and then slice and dice and toss it to the team
ViewModel
design should follow GraphPerspective work (~ 6 months out)
- has implications for Presentation layer and dependencies that require decisions about the Presentation Layer
- I/O Layer (Input from AlexA, Scooter, Brian, Thomas?)
- TBD
- requires feedback on current discussion and API proposals (see Saturday retreat agenda links)
- Command
- TBD
- Kei and Scooter may have prior art that can implemented now
- Concurrency
- TBD
- perhaps we should wait to see where the critical asynchronous use cases are before defining where to focus
- we could restrict asynchronous events only to thread safe (should we add thread safety at all?)
- goal: thread safe core
- documentation will be important for developers to know how to thread and what to look out for
Notes
- As the tasks above are accomplished and critical pieces are put into place, we should all try to identify when our plugins can be competently ported over to 3.0 to provide critical feedback on the work.