Differences between revisions 21 and 24 (spanning 3 versions)
← Revision 21 as of 2009-01-13 16:19:28 →
Size: 11972
Editor: 142
Comment:
← Revision 24 as of 2009-01-16 09:41:16 →
Size: 13053
Editor: csik
Comment: Start re-editing summary page
Deletions are marked like this. Additions are marked like this.
Line 3: Line 3:
|| '''RFC Name''' : Event Handling || '''Editor(s)''': BrianTurner || '''Date''': Nov 21 2008 ||'''Status''': Draft || || '''RFC Name''' : Event Handling || '''Editor(s)''': BrianTurner DanielAbel || '''Date''': Nov 21 2008 ||'''Status''': Draft ||
Line 7: Line 7:
~-''How the production and consumption of events should be handled; in particular how plugins interact with each other, the model(s), view(s), etc.''-~
A lot of hacks are used in the event handling framework in cytoscape
2.x. We don't want 3.0 to look like that, so rethinking the complete
framework for firing, listening to and handling events is needed.
Line 10: Line 13:
~-''Concerns have been raised on several fronts regarding event handling that cannot be addressed by simple (existing) Java patterns, largely because the application is not monolithic but is made up of independently moving parts.''-~

== Use Cases ==
This is less a listing of use cases as it is issues and concerns; an outline of what any solution should attempt to address:
Many parts of cytoscape (both 2.6 and 3.0) use the
[http://en.wikipedia.org/wiki/Observer_pattern Observer pattern].
There is a consensus that a naive implementation of the
observer pattern would not be good enough for two main reasons:

 * performance:

  Since cytoscape has to be able to handle very large networks, firing
  a seperate event for every single node for a network would cause
  significant performance problems.

 * extra features:

  Since many parts of cytoscape would be using the same framework for
  handling events, and events would strongly correspond to
  state-modification, there is a general consensus that we should try
  to stuff extra functionality into the event-framework. (The
  consensus is on ''trying'' to do this, no one knows whether we will be
  happy with the result.)

== Terminology used on this page ==

from Effective Java:
 * ''core code'' the code that provides a given cytoscape API.
 * ''client code'' the code that uses a given cytoscape API.

For example CyNetworkView is 'core code' when talking about the
viewmodel API, and 'client code' when talking about the model
API. When talking about the model API, CyNetworkView is just something
that uses that API, just as a network analysis plugin would. When
talking about the model API, CyNtworkView should not be in a special
position (more special than being an important usecase; it is
certainly not the only usecase.)

from [http://en.wikipedia.org/wiki/Observer_pattern Observer pattern] terminology:
 * ''Subject'' the object whose state-changed the event is about.
 * ''Observer'' the object that listens to the event

We should make the following distinction:
 * ''firing an event'' is the act of creating the event object and handing it over to the event-framework
 * ''triggering an event'' calling a method that results in firing an event

For example, in the current svn trunk, calling CyNetwork.addNode()
triggers an AddedNode event, but the firing is done in core code (in
the implementation of addNode())


== Issues and concerns ==
The following is an outline of what any solution should consider

Note that we don't have to address all of these at once. (There is a
considerable consensus that a 'full solution' is impossible.) It
should be pretty explicit which issues a proposal would handle and
which it would ignore
Line 33: Line 88:
== Implementation Plan ==
~-''Outline and describe the process and major issues related to implementing this proposal. Illustrate your plan when possible. Try this free online tool for making diagrams -> [http://www.best4c.com/editor/NetMapApplication.jsp Best4c] (draw; save; then insert hyperlink into this page)''-~

== Project Management ==
=== Project Timeline ===
~-''Provide a timeline for implementation. Insert a graphic if you can. Try this free online tool for making project timelines -> [http://www.helpuplan.com/index.asp Help-u-Plan] (create a new chart; modify; right-click to save gif; then attach to this page)''-~

=== Tasks and Milestones ===
~-''Outline the major milestones and tasks involved in implementation.''-~

 1. '''Milestone 1: …'''
  1. Task 1: ...
  1. Task 2: ...
 1. '''Milestone 2: …'''
=== Project Dependencies ===
~-''Outline and projects that depend on this project, link to relevant RFC's and note at what point dependent projects could be started.''-~ 		=== Dependencies ===

Many usecases are be affected by the design of the event-handling
framework. Proposals should consider these as usecases and discuss
whether they provide partial solutions for implementing these features

 * history
 * undo / redo
 * provenance tracking
 * design of web ui
Line 60: Line 109:
2. http://wodaklab.org/viewvc/svn/cytoscapeEventAnnotations/trunk
   svn co https://wodaklab.org/svn/public/cytoscapeEventAnnotations/trunk 		2.
   * http://wodaklab.org/cytoscapeEventAnnotations/xref/index.html (source code)
   * http://wodaklab.org/cytoscapeEventAnnotations (maven site)
   * http://wodaklab.org/viewvc/svn/cytoscapeEventAnnotations/trunk (browse svn)
   * svn co https://wodaklab.org/svn/public/cytoscapeEventAnnotations/trunk (checkout)
Line 255: Line 307:
##If you want to create a separate subpage for Comments, then provide this link: ["/Comment"]
 * ''Add comment here…''
=== 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.'''
Everything above should be either facts or consensus (unless clearly
marked as being a non-consensus opinion), put comments here:

RFC Name : Event Handling

Editor(s): BrianTurner DanielAbel

Date: Nov 21 2008

Status: Draft

TableOfContents([2])

Proposal

A lot of hacks are used in the event handling framework in cytoscape 2.x. We don't want 3.0 to look like that, so rethinking the complete framework for firing, listening to and handling events is needed.

Background

Many parts of cytoscape (both 2.6 and 3.0) use the [http://en.wikipedia.org/wiki/Observer_pattern Observer pattern]. There is a consensus that a naive implementation of the observer pattern would not be good enough for two main reasons:

  • performance:
    • Since cytoscape has to be able to handle very large networks, firing a seperate event for every single node for a network would cause significant performance problems.
  • extra features:
    • Since many parts of cytoscape would be using the same framework for handling events, and events would strongly correspond to state-modification, there is a general consensus that we should try to stuff extra functionality into the event-framework. (The

      consensus is on trying to do this, no one knows whether we will be happy with the result.)

Terminology used on this page

from Effective Java:

  • core code the code that provides a given cytoscape API.

  • client code the code that uses a given cytoscape API.

For example CyNetworkView is 'core code' when talking about the viewmodel API, and 'client code' when talking about the model API. When talking about the model API, CyNetworkView is just something that uses that API, just as a network analysis plugin would. When talking about the model API, CyNtworkView should not be in a special position (more special than being an important usecase; it is certainly not the only usecase.)

from [http://en.wikipedia.org/wiki/Observer_pattern Observer pattern] terminology:

  • Subject the object whose state-changed the event is about.

  • Observer the object that listens to the event

We should make the following distinction:

  • firing an event is the act of creating the event object and handing it over to the event-framework

  • triggering an event calling a method that results in firing an event

For example, in the current svn trunk, calling CyNetwork.addNode() triggers an AddedNode event, but the firing is done in core code (in the implementation of addNode())

Issues and concerns

The following is an outline of what any solution should consider

Note that we don't have to address all of these at once. (There is a considerable consensus that a 'full solution' is impossible.) It should be pretty explicit which issues a proposal would handle and which it would ignore

  1. Batching: The case where many events (like the creation of many nodes) could possibly be grouped together as opposed to handling each one discretely.

    • What does batching mean? In Eclipse a batch is defined as set of nested events:

      It is important to note that the broadcast does not necessarily occur immediately after the method completes. This is because a resource changing operation may be nested inside of another operation. In this case, notification only occurs after the top-level operation completes. For example, calling IFile.move may trigger calls to IFile.create to create the new file, and then IFile.delete to remove the old file. Since the creation and deletion operations are nested inside the move operation, there will only be one notification.

  2. Transactions: Plugins should leave the model in a valid state, and conflicting changes by different plugins prevented. However not all plugins are about editing. Some plugins maybe passive, providing a view like an outline, in which case they should not have to concern themselves with the added complexities implied by participating in a transaction. In Eclipse a contributor to a perspective extends/implements either IViewPart or IEditorPart to help make this distinction in roles.

  3. Mode: Event handling needs to take into account modes of running like headless.

  4. Event Object: What information should the event object contain? Using another eclipse example:

    • The resource it corresponds to.
    • The kind of modification (added, removed, or changed).
    • The precise nature of the change (the change flags).
    • A summary of what markers changed on the resource.
    • Deltas for any added, removed, or changed children.

  5. OSGI: Event handling should reflect and build on the architecture of OSGI, and may therefore be implemented using the concept of a white board.

  6. Abstraction: Plugins should not deal with low-level UI events, e.g. mousePressed, but rather with semantic events that Cytoscape provides, e.g. objectOpened instead of mousePressed() with (e.getClickCount == 2).

    • drag/drop may be a special case. What layer of semantics would Cytoscape want to provide above the Java paradigm of Transferables and DataFlavors?

Dependencies

Many usecases are be affected by the design of the event-handling framework. Proposals should consider these as usecases and discuss whether they provide partial solutions for implementing these features

  • history
  • undo / redo
  • provenance tracking
  • design of web ui

Link to other related RFCs

Prototypes

1. Svn+ssh://Grenache.ucsd.edu/cellar/common/svn/csplugins/trunk/Agilent/creech/BAMEventModel

2.

Issues

Batching

The problem with batching can be imagined in this way: When deleting a node (especially now that nodes exist w.r.t. only to a model, and not independently of it), listeners need to know about the node AND its context before the node is actually deleted. Thus, in a batch of events, with a naieve implementation, the node would already be gone by the time the batch was received. To circumvent this you might flag the node as being "marked for deletion", but this means, for the duration of the batch, every piece of the code the examines and graph and its nodes, needs to be sensitive to this state. (Updates can present similar issues, but deletion is the best example.)

Why did we want batching? Originally to address the issue of excess "noise". It should be noted that there are ways of reducing noise without batching all events. You, could for instance, just batch similar event types. However the failure to be able to apply a batch to any and all events means concepts like transactions if they are to be arbitrarily defined as a 'unit of work' independently of the code being batched is not possible.

Why not deal with batching later? Because batching (in a transactional sense, or any other higher level abstraction that groups events) does appear to be implementable without making changes to the API, something we wish to avoid in future releases. This is an assumption and it is possible someone might think of a way to introduce batching or transactions later on that don't affect the API, but in building the two prototypes, this does not seem likely.

Do we care about transactions? Isn't easier to leave them out? It is, as we discovered, however that was not our original intuition. We all thought batching would be easy. As well, introducing higher level abstractions about events, like "Undo/Redo" and "Transactions" seems like a natural progression in event handling, like hyper edges and group nodes in graphs. While the need for these things may not exist now, it doesn't seem unreasonable to imagine that we might at some future point, wish we had these capabilities and it is likely that other people will think as we did, that batching is natural extension to event handling, but of course, allowing for it comes with a price. Batching may come at such a price that the trade offs don't make it worth it.

Event Examples

VistaClaraPlugin

Events Consumed

Cytoscape

  • beans.PropertyChangeListener (Cytoscape.SESSION_LOADED) Cytoscape.NETWORK_LOADED - update UI buttons Cytoscape.NETWORK_DESTROYED - update UI buttons Cytoscape.NETWORK_MODIFIED - update UI buttons JTable Model changed - update UI buttons

    Addition/removal of CyAttributes (MultiHashMap DataDefinitionListener) Cytoscape.SAVE_PLUGIN_STATE - save VC state with session Cytoscape.SESSION_SAVED - update VC state info Cytoscape.RESTORE_PLUGIN_STATE - read in saved VC info

    CytoscapeDesktop.NETWORK_VIEW_FOCUSED - track network for following selection events

    CytoscapeDesktop.NETWORK_VIEW_CREATED - track network for following selection events

Events Produced

  • Various JTable model changed and structure changed events

    ColumnSelection VCTableChangeListener (internal event) - refresh heatstrips

AgilentLiteratureSearch

Events Consumed

Events Produced

  • ALSInitListener (internal event) Cytoscape.PREFERENCES_UPDATED

HyperEdge

Events Consumed

Events Produced

Comments

Everything above should be either facts or consensus (unless clearly marked as being a non-consensus opinion), put comments here:

Outdated_Cytoscape_3.0/EventHandling (last edited 2011-02-24 16:27:51 by PietMolenaar)

Funding for Cytoscape is provided by a federal grant from the U.S. National Institute of General Medical Sciences (NIGMS) of the Na tional Institutes of Health (NIH) under award number GM070743-01. Corporate funding is provided through a contract from Unilever PLC.

MoinMoin Appliance - Powered by TurnKey Linux