Some talking points for the mini-retreat

This page was originally very long and listed a bunch of questions. I moved the ones that we didn't have time to discuss to DanielAbel/VisualizationQuestions

The following is a list of questions / issues that I would like to ask others' opinion on during the mini-retreat. Some of these are strictly speaking not questions, but suggestions for discussion. Feel free to edit/comment either in-line or at the end.

Is 'selection' a viewmodel or model property (state)?

Currently in core3/model it is in the model layer, does it obviously belong there? Could it allow multiple different selections? (as described at the end of the PluggableRenderers page.)

In the model, is it the property of the CyNode/CyEdge or the CyNetwork?

resolution

It will be a viewmodel property, implemented with 'subsets'

Serialize VisualStyle, or result of applying it?

Currently (in 2.6.1) saving a network in xgmml and then reloading it will corrupt the VisualStyle: the VisualStyle that is reloaded turns all mappings into DiscreteMappings. Basically what is saved is not the VisualStyle, but the result of applying that VisualStyle. Should 3.0 do the same? (I think properly saving the VisualStyle instead should be possible. It might break upstream-xgmml compatibility, i.e. make 'cytoscape xgmml' a bit incompatible with the 'upstream xgmml' standard, but that already happens with allowing mixed networks and due to the fact that cytoscape uses bad default values in some cases.)

Would saving the result of applying the VisualStyle be usefull for compatibility? Are there non-cytoscape tools that can read the visual attributes Cytoscape includes? (I think the constants used for serializing look like they are non-cytoscape constants.)

resolution

Serialize the result (which is the viewmodel state)

Questions about possible new features:

Event-coalescence optimization

In the vizmapper GUI there was an optimization implemented which ignored events fired during session load. (The implementation had an 'ignore' boolean field which was set in the 'loading begins' event handler and cleared in the 'loading finished' event handler, and all other event handlers ignored events if it was set.) This should be implemented in a less ad-hock manner: whoever fires/initiates the events should be able to give hints to the event-handling framework like 'collect, don't fire events' and then 'fire all events collected so far'. The event firing framework should then be able to fire a single event instead of many small ones (for example, when loading a network, instead of firing an AddedNodeEvent for each node, it could fire a single AddedNodeEvent at the end. Of course this event will be more of a AddedNodesEvent, with a Collection<CyNode>getNodes(), for example.) I think this will be helpful to avoid problems like bug no. 1941 (http://cbio.mskcc.org/cytoscape/bugs/view.php?id=1941) especially since the events (as far as I can tell from the current code in core3/model/trunk/src/main/java/org/cytoscape/model/internal/ArrayGraph.java) are fired by the method that does the action, and not by the one that initiates the action. I.e. with the current code in core3/model, if I create a bunch of nodes, I will have to do that by calling CyNetwork.addNode() one-by-one, which will fire AddedNodeEvent one-by-one, which means I can't even do the "collect nodes to add and then add them in one go" trick suggested for fixing bug no. 1941.

Of course, such automatic event-coalescence might be very tricky to do right. For example, if one can subscribe to events of a single item, then events for a bunch of those items can't all be replaced with one event. (But such specific event listener subscriptions are not supported now.) If trying to implement something like this is deemed too risky, all events that can be mass-fired in usecases should / must support mass-actions (like being able to select a lot of nodes at once), so that "collect items to operate on and then do it in one go" optimizations are possible.

Note that doing event-coalescence hypothetically might defeat some sorts of possible parallelism in event handling (i.e. one processor loading the network while another network handling the AddedNodeEvent-s one-by-one), although I am quite suspicious such parallelism wouldn't provide much of a speedup.

resolution

Debated at mini-retreat; since then, many proposals were suggested, see RFC

supporting provenance-tracking?

Does the event-firing framework need to explicitly support provenance-tracking? Logging all the events that are fired would certainly capture a lot of information, but it might be too low-level.

How will the framework help make supporting provenance-tracking trivial? (Or how would it enforce that it is accuratelly done?)

If provenance-tracking is done in the Command layer, would that still be able to guarantee accuracy? I.e. would all plugins be aware of provenance tracking and would the correctness of all plugins be required for accuracy? Would we want to force all plugins to make modifications through a layer that would enforce provenance tracking? (How would this layer differ from the model layer, and why would it be seperate from it?)

resolution

Debated at second mini-retreat; will be discussed further.

Questions about implementation issues in pluggable-renderers:

Larger refactorings done in pluggable-renderers branch

Is everyone okay with the larger refactorings I have done in the pluggable-renderers branch? Since the 2.6.x architecture of some layers made further development really hard, I simplified and refactored it in some cases. This means that the pluggable-renderers branch contains not only changes related to pluggable rendering, but also changes which simply refactor existing functionality.

These larger refactorings are: (hopefully complete list)

1. removing Appearance-layer: there was a complete layer of

   NodeAppearance, EdgeAppearance, EdgeAppearanceCalculator, etc. classes between Mappings and NodeViews. Since it didn't seem to serve any usefull function, it just connected those two, I removed it all. (svn rev. r14617 and r14618)

2. Removing the idea of having a 'global current VisualStyle'. (svn rev. r15150)

3. fixing all cases where the name of VisualStyles are passed around instead of the VisualStyles themselves. (svn rev. r15161)

resolution

Since no-one objected, I assume these changes are acceptable.

DependentVisualProperty feature

Is everyone comfortable with the DependentVisualProperty feature? See on the pluggable-renderer page.

resolution

Since no-one objected, I assume this feature is acceptable.