Next: Wavelet Lessons Up: Lessons from the Neighborhood Previous: Programming with Constraints

## Distributed Constraints

Imagine a group of neuroscientists in different locations, browsing through the same brain data set. As they work together, they need all their data views centered on the same position in the brain, and need to have their views updated as any of them changes. Each neuroscientist may also disconnect from the group, browse independently, then reconnect and either move to the global position, or request others to move to her position. Normally, any participant should be able to move everybody's views; however, a chairperson can be selected and made the only user allowed to control navigation. The collaborating neuroscientists thus need to control the amount and type of their interaction.

This principle, known as flexible coupling [4], is common to many collaborative applications. Users must be able to dynamically connect to a session, disconnect, work independently, then reconnect.
GroupKit [6] defines a rich API to manage sessions, among other things. Different collaborative applications require different degrees of synchronization and consistency. We can meet these requirements with flexible update propagation: variable updates may propagate immediately, after being validated by the application, or only when the user explicitly commits them. Depending on the number of participants and the formality of collaboration, different access control methods at variable granularity are needed. Examples are floor control, locking individual variables, and locking groups of related variables.

The constraints provided by TclProp, while effective for simple coordination of multiple linked views, are not powerful enough to implement flexible coupling of multiple users on multiple machines. To address the demands of collaboration, we needed to develop distributed constraints.

Distributed constraints provide a good framework for implementing flexible coupling for collaborative applications. We developed a distributed constraints module by extending TclProp to handle network communication using Tcl-DP [8], and implemented some features of flexible coupling. Dynamic disconnection and reconnection are supported by disabling and re-enabling constraints on variables of the specified view. The shared floor-holder token provides the floor control policy. Flexible update propagation is currently supported in the application, not at the toolkit level. We are currently examining ways to integrate flexible coupling into a distributed constraint module based on TclProp, and we plan to release that module at a future date.

We benefited from using distributed constraints in several ways. We were able to allow collaboration between geographically distributed neuroscientists, without significantly increasing code complexity compared to the single-user, multi-view version. As local constraints maintain views in the single-user prototype centered on the same point, distributed constraints ensure that all collaborating users see the same brain data. We achieved this by declaring distributed constraints between the coordinate positions of individual users, and the global group position. For flexibility, these constraints added a level of indirection--each user now has a "personal" coordinate that is linked by local constraints to the individual views. In this way, a user can systematically view the brain at an offset from the group view. For example, an individual neuroscientist may choose to view the brain 10 microns deeper (in the z-direction) than her colleagues, and at the same x and y coordinates. Her viewer would link to the global coordinate system as follows:

    # link local x and y to globalX and globalY

    DTP_inLink  $host $port globalX x
    DTP_outLink $host $port globalX x

    DTP_inLink  $host $port globalY y
    DTP_outLink $host $port globalY y

    # link local z to globalZ+10 and vice versa

    DTP_inFormula  $host $port \
        z globalZ {expr $globalZ + 10}
    DTP_outFormula $host $port \
        globalZ z {expr $z - 10}

Neuroscientists can disconnect from the collaborative session and navigate through the image data independently, while keeping their personal views of data consistent with one another. This is achieved by temporarily disabling constraints between the group position and user position, while retaining the constraints between the positions of this user's views. Similarly, they can still unyoke individual views from their personal coordinate system, whether connected to or disconnected from other users. Figure 3 shows how connection and disconnection are supported.

: Flexible coupling in the neighborhood viewer. The constraints linking Jean's views with Pat's views can be disconnected at the user level (top-right) or at the view level (bottom-left).

We are experimenting with other flexible coupling models, such as floor control, within the neighborhood viewer application, and we plan to move support for these models into our Distributed TclProp module as soon as possible. We are also investigating new models including group awareness through queries into the distributed constraint table.

Incidentally, the use of distributed constraints provided our users with a valuable application feature that would have otherwise been difficult to implement. With limited screen real estate and local image processing resources, it is convenient for a single user to use several workstations and monitors, each holding a different view or set of views. Our distributed constraint approach makes implementing this feature trivial, and also provides a mechanism for distributing pieces of images that are larger than a single screen across several monitors with linked scrolling. We expect this approach both to improve performance (by parallelizing expensive image loading) and to expand the horizon of interfaces that the neuroscientists can imagine.

To summarize, we developed a distributed constraint model based on TclProp [5] and Tcl-DP [8]. Our model supports a rapid design-code-invent cycle, implements some features of flexible coupling, and supports multiple, modifiable constraint configurations. By adopting the distributed constraint model, we achieved collaboration and local speedup in the NV while keeping the code readable and extensible.

We discovered, in the process of developing and using distributed constraints, that the key to flexibility is providing places in the constraint topology where links can be disconnected. It is important to have intermediate nodes in the graph representing users and views, to provide a site for local disconnection and transformation. Providing these intermediate nodes has not been very difficult and our observations have shown that the bottleneck of distributed constraints lies in network communication, not local constraint propagation. Therefore, any slowdown is negligible (indeed, the entire distributed constraint system performs comparably with RPC).

Finally, we believe that distributed constraints can be particularly beneficial for collaborative systems that require synchronous navigation through sets of spatial data. Examples of such application domains are medical and biological imaging, GIS, and collaborative data visualization in general.

Next: Wavelet Lessons Up: Lessons from the Neighborhood Previous: Programming with Constraints