Cytoscape WikiIlianaAvila (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 in 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.
AllanKuchinsky(2.1.06). I agree that this touches upon broader API design issues. Also, a number of us in the metanodes 'group', who have read the RFC, have also observed that our approach has been to first solidify the use cases, then define the APIs necessary to support the use cases, then structure the implementation based upon the requirements of the API. A while back -- I think about a year ago -- we talked about doing a kind of "model/view/controller" analysis on how Cytoscape currently is put together and how it might be better structured. Perhaps now is the right time to be doing this kind of analysis, particularly since the rendering interface is being overhauled.