Diff for "Hackathon2005"

This is just a brainstorming session right now. We can prioritize discussion and ideas for projects later.

• Discuss the difference between node hide and delete concepts -> Goal: get conceptual clarity and a plan to document/implement any necessary changes based on this. Also select/deselect vs. flag/unflag

• Improve conceptual clarity and better document the core and graph model - Is the root graph a multigraph or a graph? Is the root graph directed, undirected or mixed? How about graph perspective? Can nodes or edges be duplicated? etc.
• Discuss switching to a numbered node system instead of the current node ID as a string system
  • This may be required for some graph editing use cases (having nodes with no name yet) and two nodes with the same name.
• Discussion of undo manager
• Prioritize subsystems for refactoring
• Discuss new documentation options e.g. wiki based, which can be translated to PDF and Java help.
• Plan core code cleanup - removing old libraries, old classes, clean up of package structure
• How can we package code so it is easier for developers to load - we have a problem with core plugin and library code being in too many places.
• Clarify and document the difference between core and non-core and decide on policies for making future decisions on this.

• Review community development process and core coding conventions, etc -> goal is to increase quality of our codebase and application

• Discuss user interface standardization issues (Benno brought this up 2 years ago)

• MetaNodes

• Discussion of how to handle "compound" node types -- e.g. complexes, families (sets) (related to MetaNodes above...) (Note: I'd like to make this a high priority for discussion. Alex Pico of the GenMAPP project will be participating in the Hackathon and can go into considerable depth on the requirements for these constructs. It would be very useful to have this discussion while we have the opportunity to pick Alex's brain).

• Discuss new rendering engine that Nerius is building
• Simplifying file formats and implementing the save session feature. Does .sif need to have two ways to specify interactions? Do we need GML if we have a save session file?

HACKATHON NOTES: File formats

Current types of file formats in Cytoscape:

• sif, network, i/o
• gml, network, i/o
• noa, attr, i/o
• eda, attr, i/o
• expression, TP, i/o

• .onto, .anno, .syno, .obo (BioDataServer)

• GO .onto, .anno, .syno, (Kei)

Issues on each file format:

• expression file: should be a noa file
• GO: information gets loaded onto runtime memory, not reasonable for big species,(different topic: databases)
• GML: We are not respecting the format. Node integer IDs are ignored.

Action items:

• Test Rowan's file format for attributes

Related topic:

• State saving
  • Kei is working on this for 2.3. Summary of his strategy:
  • zip contains all needed files
  • network files: XGMML
  • cysession.xml: tree strcture of loaded nets, cyto-panels state
  • vizmap.props
  • cytoscape.props
  • Uses JAXB (Sun library for serializing)
  • schema files are used to define contents of XGMML and XML files: XGMML.xsd, cysession.xsd Questions/Issues/TODO on saving state:
  • how do we package? zip? Group agreed to use zip.
  • save sif files or XML files? Maybe an exporter between the two formats would be a good solution.
  • Package all files inside a directory that then gets zipped (so that when it gets unzipped, all files are within a single directory)
  • Time-stamp the zip
  • Naming issues: .cys or .cyto file extension
  • Plugins should be able to save their state. A listener for "state saving" would be a good strategy. Plugin coders would be responsible for saving their own state (writing and reading). Details are somewhat complicated, but we all agree that it is doable. This is not planned for 2.3, but we can discuss it.
  • Optional interface to select files that should be included in the zip? Maybe just add option to delete attributes or other types of data that user does not want in the state. This probably belongs to the deletion item in this list.
• Do we need to standardize context menus for nodes and edges or is the current model fine? It seems to be working fine, but will it scale? One reason for standardizing in the core is that the current model uses Piccolo and that may be replaced.
• Cytoscape and databases. For example, GO structure is too big, and should not be loaded into runtime memory. Would be nice to have a database API.
• ID mapper services. Hard bioinformatics problem. Very much needed.
• Please add your discussion points here.