## page was renamed from RFCTemplate ## This template may be useful for creating new RFC's (Request for comments) ## This is a wiki comment - leave these in so that people can see them when editing the page ##Fill in RFC Name, primary authors and editors, and the status of the RFC ##Example Status states include: Work in Progress, Open for Comment, Closed || '''RFC Name''' : Code Layering || '''Editor(s)''': Alex, Sarah || '''Status''': Open for Comment || <> == Proposal == ##The sections below may be useful when creating an RFC, delete the ones that are not '''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. ##If you want to create a separate subpage for Comments, then provide this link: ["/Comment"] === 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.'''