Web-Enabled Cytoscape

One of the goals of Cytoscape 3.0 is to provide support for a web-client interface to Cytoscape. There has been lots of discussion about that, but no specific use cases outlined that have enough technological detail that allows us to refine the design. My perspective is that there are three possible use cases (and, of course, everything in between) that we can use to define the range of possible target design criteria. The goal is to engender a discussion about where on the web-enabled continuum we are trying to hit for this design, and what possible design implications there are. I'm sure my terminology can be refined, and there may be lots of details about how I've characterized each of these that people may disagree with, so feel free the chime in. The three use cases, as I see them, I've called Cytoscape-Web, Cytoscape-Services, Web Network Visualization. These decrease in complexity so we'll take them in reverse order.

Web Network Visualization

In this use case, Cytoscape is not a main feature of the overall application. A Web application has been written that is used to visualize networks and possibly associate information or actions with the nodes and edges within those networks. The application might want to use some of the analytical features of Cytoscape, but not necessarily in an interactive fashion. For example, a user might want to cluster the network using MCODE or MCL, but doesn't expect any interaction or feedback during that process other than something telling the user that things are still alive. The general mode of interaction with Cytoscape is very "webby" -- that is, completely stateless and (for the most part) batched. The user visualizes the network, moves things around performs annotation, or whatever, all without using any aspect of the Cytoscape core. Then at some point, the necessary information is bundled together by the web client, shipped to a CGI or server-side program written by the application author, which calls Cytoscape in headless mode, perhaps passing it command arguments or calling Commands directly though some scripting interface. A key aspect of this scenario is that there is no (or very limited) interaction between the web client (e.g. the Javascript running on the browser) and Cytoscape.

Cytoscape-Services

This represents an intermediate use case where the web application is not provided by Cytoscape, but there is a tighter interaction between Cytoscape and the web application. For example the web application might want to take advantage of Cytoscape's data table mechanism and reflect that to the user, provide a tighter coupling between the web application and layouts, or provide more dynamic access to plugins that allow iterative exploration of the data set. In this example, there might be a desire for the web application to share knowledge about the user's interactions with the network (e.g. selected nodes and edges), and for the Cytoscape server to share information about it's internal state back to the web application (e.g. creation/modification of attributes, network changes, etc.). I would imagine this is still somewhat loosely coupled in that Cytoscape is not actually doing the visualization. Rather there is a stub view (as opposed to the headless view used above) which does little more than communicate certain state information upon request. In this example, there is ongoing interaction between the web client (Javascript in the browser) and the core application running on the server.

Cytoscape-Web

This is the most complex use case. The idea is that we (Cytoscape) provide as much functionality as possible through a web ui as possible. Ideally most of the Cytoscape core functionality would be provided, and there would be mechanisms (Tunables, etc.) that would provide a way for plugins to interact with a web-based user. Some plugins would need multiple user interfaces (e.g. clusterMaker's HeatMap visualization), but other's would not (e.g. clusterMaker's MCL algorithm). This user interface would provide network browsing, manipulation, attribute (CyDataTable) browsing, network and attribute importing and exporting, and the full power of the VizMapper (although not necessarily all of the same visual attributes).

Implications for Cytoscape 3.0

Those are the three use cases. Each has a different set of design implications for Cytoscape 3.0. In the first case, we can assume (hope) that the network size is limited and we don't need to maintain state. The "view" is headless, and provides nothing more than X,Y coordinates. The only possible modification to a headless version of Cytoscape to support this is to think seriously about how we would serialize the network in a more efficient way than XGMML, but more functional than SIF. If the assumption that we're dealing with limited networks is not true, we're going to see definite performance issues with Cytoscape startup and network load. There will be no user-initiated events, so we can assume all user-initiated events are local and can probably define them in Swing terms since that will be our only UI. In the third case, we have lots of fun to think about. Clearly, events are impacted, and this would mandate a stateful server, I think. There might also be implications for the I/O layer to allow import of attributes/networks to occur from the browser rather than from the file system or through a URL (our current assumptions). I think we would also need to provide an infrastructure that a plugin could use to get an "area" in the user interface. Currently, a plugin can assume it can get a graphics context from Swing and paint to that context -- what takes it's place in this true web-ui. And user interface events would now have to flow from the browser to Cytoscape and we would need a much more expansive (or restrictive) definition of these events. Finally, in the middle case (which is actually just a rough mid-point in the continuum between the first and third use cases), there is the potential for either greater or lesser coupling. The more support for coupling we provide, the more a web application author will be able to take advantage of Cytoscape services. The less we provide, the more restrictive that interaction and use of services will be. A big question about this use case is where the view itself will be handled. Is the web view something that lives within Cytoscape (like the third use case) or completely separate

Our issue here is not to provide implementations of any of the above solutions (even the last one) but to decide whether we will want to in the future. If we believe all of our current and future use cases will be loosely-coupled and the networks small enough that the web client can serialize the network, send it to a server-side script, which will initiate Cytoscape, hand it the network, operate on the network, and sent back the updated serialization of the network (sounds complicated, but perfectly reasonable for small networks) then I don't think there are any design implications. We can essentially ignore the Web as a criteria beyond ensuring that Cytoscape provides a headless mode that does not assume any UI. If, on the other hand, we can envision user cases with tighter coupling, we have more work to do.

Implications for plugin authors

The implications of all of this for plugin authors is significant. In the first case, if your plugin assumes a UI beyond setting tunables, it can't be used -- full stop. As a plugin author, I really don't like that approach -- it is certainly my goal to see my plugins used by the community even after the paper is published, and the more use, the happier I am. It's pretty clear to me that many of the plugins I write will not translate to this model. Metanodes have no meaning, and most of clusterMaker provides little general functionality. Pretty much the only things I can imagine are those plugins that either (a) return a single, simple result, or (b) modify the state of the network in a way that can be returned. Obviously, the third option is most attractive to me. I can leverage as much of Cytoscape as possible in my plugin, including assumptions about visual network state, and only have to provide additional components when I really step outside the norm. For example, clusterMaker would have to have a TreeView visualizer for Swing as well as for the Web. All I would need from Cytoscape is the mechanism to get that UI back to the user in some fashion. The middle case represents the hardest use case to characterize from a plugin author's perspective. If we're on the "loosely coupled" side of the continuum, then much of the functionality I currently get from the Cytoscape application will probably not be available. Essentially, I would guess this would be functionally like headless mode. If my plugin made sense in headless mode, it would make sense in a loosely-coupled web mode. If, on the other hand, the coupling is not as loose, then more possibilities exist for user (and network) interaction, and my plugin could provide more functionality. But again, the more tight the coupling, the more there needs to be some infrastructure provided by Cytoscape to allow my plugin to take advantage of that infrastructure