Cytoscape WikiIliana: Here is my opinion on each of the proposed data structures:
CyAttributes Requires that a node (if we use node CyAttributes) or an edge (if we use edge CyAttributes) be created per group. Only in one case (COLLAPSING_STRATEGY) is a node per group needed. The other grouping strategies do not need new nodes or edges. Additionally, there is no safe way of storing information that tells us to which network a group belongs, since the node that functions as a key in CyAttributes can be manipulated very easily by users (removing it, adding it to a new network, etc).
CyNode Also requires a node per group. This was originally done because when we were designing the GINY API, we were not thinking of the more general grouping problem. We were thinking of MetaNodes only.
A new data structure. This could be a data-structure that resembles CyAttributes (some sort of map structure) but that does not require the creation of a node per group. Also, this data structure would be hidden, so that the only way of interacting with it is GroupingManager. I vote for this.
*GaryBader - if we don't use the GINY implementation, then what will happen to all of the child and parent methods in GINY? Should they disappear? If so, the CyNetwork definition changes (becomes much simpler), since it would no longer support a compound graph structure.
* IlianaAvila - The question is, should GINY be a simple graph (nodes, edges, and nothing else) and additional complexity added on a different layer, or, should GINY be a complex graph (with support for nested graphs). I don't think there is a right/wrong answer. Many factors need to be considered, like, API cleanliness, code performance, etc. Maybe Nerius could tell us about this, since he seems to be rewriting our graph API.
GaryBader - The giny methods are inefficient for grouping/ungrouping, since it seems you have to add all nodes and edges in the subnetwork individually to the group. The API you proposed adds a whole network to a group in one operation. CyAttributes would be inefficient to traverse (though not a major problem) So it seems that a new hierarchical data structure is the better choice and that all the giny child/parent methods would have to be deprecated/removed and the core giny model would revert to a simple binary multigraph. This would simplify the core significantly and would move the group concept to a separate API where it would only be used by those who needed it.
IlianaAvila - I like Gary's idea. It think this is where we are moving towards anyway.