RFC Name : Code Layering |
Editor(s): Alex, Sarah |
Status: Open for Comment |
<<TableOfContents: execution failed [Argument "maxdepth" must be an integer value, not "[2]"] (see also the log)>>
Proposal
Code Layering - for the purpose of enabling a command layer (headless mode) and different front ends (e.g., web-based or SVG). Some may see this as refactoring, but I think we can identify critical feature-based goals that derive from code layering that can be more readily justified as project aims that are typically expected to produce something "new".
Use Cases
Headless Mode: Something we talked about having for a while. Do people have particular projects that would benefit from this?
Web-based Front Ends: there is evolutionary pressure for software these days to be more web-based (versus stand-alone or even web start). Can we come up with specific projects that would make use of this?
Cytoscape Server: many at ISB would utilize this for larger network analysis projects and several would embed it into internal and external web sites
GenMAPP-CS funding is starting in August and we plan to hire someone to work on this sort of development in Cytoscape to expand the client options.
WikiPathways.org might be able to embed a special front end of cytoscape for advanced pathway analysis
http://t1dbase.org would like to be able to use Cytoscape directly through a web front end (Nat Goodman has directly requested it several times)
add here
General Notes
Model:
- All the graph (giny) APIs, Node, Edge, Network etc (See Scooter's comment - sk)
- ?? (someone with more knowledge of the core code...)
View:
GUI interface (NodeView, EdgeView, NetworkView) (See Scooter's comment - sk)
- Web interface
- Headless
Controller/Observer (something to handle events):
- Events, listeners here
- Respond by invoking changes in the model
Requirements
Backward Compatibility
- Identify critical areas effected by layering:
add here
Implementation Plan
- Identify collections of classes to be layered
- Layer the code
- Develop new features
Comments
July 25, 2007: ScooterMorris
This may belong in a separate RFC, but with the discussion of scripting interfaces, and all of the complexity that we all had to understand to be able to program in Cytoscape, I'm wondering if we could being the process of providing a cleaner abstraction to the API layer of Cytoscape. I would propose we could do this by implementing CyNetwork, CyNetworkView, CyNode, CyNodeView, CyEdge, and CyEdgeView interfaces that would provide most of the necessary functionality that is now provided by the Cy* classes and the giny interfaces. This would greatly simplify some of our layering efforts, and eventually put us in position to replace the current giny/ding/fing backend if something better came along. This is a long process and will take several releases to complete, I'm sure, but with the layering and scripting discussions, I thought now might be a good time to begin the process.
How to Comment
Edit the page and add your comments under the provided header. By adding your ideas to the Wiki directly, we can more easily organize everyone's ideas, and keep clear records. Be sure to include today's date and your name for each comment. Try to keep your comments as concrete and constructive as possible. For example, if you find a part of the RFC makes no sense, please say so, but don't stop there. Take the extra step and propose alternatives.