Whiteboard Meeting

We have implemented a whiteboard tool[17] which can be used either in a single-user mode or in a multi-user mode. In the former case, the user can draw, delete, and modify objects such as lines, circles, and free-hand pictures, load images, etc. In a multi-user mode, COCA can be used to enforce specified coordination policies such as those for access control, concurrency control, and session control. For example, a policy can be specified where, when a user attempts to annotate an object, the command is sent to the owner of that object. If the owner personally does not like the annotation, then it will not appear on both parties' whiteboards and will not be propagated to other sites. In the following, however, we only consider a simplest case in which everybody can do anything and what you see is what I see (WYSIWIS). In[17] we showed how the same whiteboard tool can be used under many different coordination policies.

 

Figure 4:   A policy for WYSIWIS meeting.

In this specification, each command from the whiteboard is propagated to all participants and any commands from other sites are sent to the local whiteboard, both without examination. However, conflicts can arise. For example several participants may happen to modify the same object on the screen. Some concurrency control policy must be enforced to resolve such conflicts. Here for simplicity, we adopt a floor control scheme in which participants take turns to draw on the whiteboard. Specification of other concurrency control policies (e.g. [9]) can be found in [15].

In a floor control scheme, a particpant must have the floor to draw on the whiteboard. We change the first rule to the following.

on-arrival(gate(local-in), Cmd) :-
    isa(self, holder),
    remote !(Cmd).

Each time the local participant attempts to draw an object, the command is not propagated to other sites unless the participant currently is the floor holder. Note this policy is not complete. It says nothing about how to become a floor holder.