Cytoscape Wiki|
Size: 3157
Comment:
|
Size: 1498
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 8: | Line 8: |
|
Detailed list of tasks to push ahead with OSGi adoption and assessment. Names and estimated deadlines included. = Tasks = ##bullet point list of discussion items, in order of discussion 1. 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 (Alex, 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. 1. Cytoscape Presence (ISB + Alex, Kristina - December?) * collect materials: video ideas, tutorials, course material, selected publications (scivee?) * build, identify infrastructure for this material * deploy * discuss consistency/style guidelines 1. Cleaning up all warnings and mvn find bugs (Everyone!) * a lot of these are unchecked errors * site hackathon? * split up arbitrarily 1. Graph''''''Perspective <-- new Cy''''''Network (Mike -> Everyone!) * implications for Cy''''''Node''''''Attributes, Cy''''''Edge''''''Attributes * 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 1. View''''''Model * design should follow Graph''''''Perspective work (~ 6 months out) * has implications for Presentation layer and dependencies that require decisions about the Presentation Layer 1. I/O Layer * TBD * requires feedback on current discussion and API proposals (see Saturday retreat agenda links) 1. Command * TBD * Kei and Scooter may have prior art that can implemented now 1. 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 |
Discussion of Network and Attribute Model |
| Line 51: | Line 10: |
|
== Notes == ##This section will contain notes from the session, as input concurrently by multiple attendees (we may want to use Google Documents for this) * 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. |
= Network and Attribute Model = * Trey's "five minutes" * tweak #1 - every node should have a unique ID per session (NID) * tweak #2 - attributes should have unique IDs as well (AID); each NID is associated with a set of AIDs; related nodes may share many attributes; where data is shared, references are used === Something Approximating Concensus === * each loaded node has a unique ID (NID) * a unique binding table of NIDs <-> Names exists per network * data is loaded as one or more worksheets, keyed by node Name * when you load a worksheet, you have to specify which (if any) networks to apply the data (default = currentNetwork) * when you load a network, you have to specify which (if any) worksheets you want to apply (default = all?) * as a UI point, you could also preselect networks (or worksheets) prior to loading worksheets (or networks) to indicate binding * when a worksheet is applied to one or more networks, a reference is placed in the network binding table to the worksheet cell * data table cells should be able to reference other cells, networks, vizmap properties; cells could contain formulas as well |
Continued Design Discussions and Wrap Up
Date: Saturday, July 19, 2008
Description
Discussion of Network and Attribute Model
Network and Attribute Model
- Trey's "five minutes"
- tweak #1 - every node should have a unique ID per session (NID)
- tweak #2 - attributes should have unique IDs as well (AID); each NID is associated with a set of AIDs; related nodes may share many attributes; where data is shared, references are used
Something Approximating Concensus
- each loaded node has a unique ID (NID)
a unique binding table of NIDs <-> Names exists per network
- data is loaded as one or more worksheets, keyed by node Name
- when you load a worksheet, you have to specify which (if any) networks to apply the data (default = currentNetwork)
- when you load a network, you have to specify which (if any) worksheets you want to apply (default = all?)
- as a UI point, you could also preselect networks (or worksheets) prior to loading worksheets (or networks) to indicate binding
- when a worksheet is applied to one or more networks, a reference is placed in the network binding table to the worksheet cell
- data table cells should be able to reference other cells, networks, vizmap properties; cells could contain formulas as well