SimplifiedMetaNodeDataStructureRFC_comments

IlianaAvila (1.31.06). Your motivation for the changes you suggest is that the GINY API contains too many methods for metanodes. Then, this is an API problem that we should first try to solve by studying the API itself. I counted 25 unique methods that deal with metanodes across 3 classes (GraphPerspective, RootGraph, and Node). If GINY did not have both node/edge integer indices AND Node/Edge objects, then this set of methods could be reduced to 12. If you then take away the methods whose purpose can be met using other lower level metanode methods, you are left with about 2 or 3 methods (and these are the ones I use in the metanodes plugin). So, the problem you are trying to solve can be solved by working only on the API. I would also argue that the cause of this problem is not a metanodes problem. I think it is a larger scope problem in the GINY API. It contains too many methods to do one thing. For example, there are about 10 methods related to getting the degree of a node. That does not mean that getting the degree of a node should be dealt with Cytoscape attributes. Metanodes can be implemented many ways. You can do it by adding support for them in the graph model, or a separate data structure (CyAttributes or another map). Whatever the back end implementation is, the API will still be the same, whether the methods are in GINY or in a separate library/plugin. And really, your idea is not that different from the way it is done now in GINY. In your implementation, your CyAttributes key is the metanode identifier, and the value is a CyNetwork pointer. In the current implementation, a Node points to a GraphPerspective through Node.getGraphPerspective() and Node.setGraphPerspective(). I think it is pretty much the same.