Floor control is often used in CSCW systems to control the mutual exclusive access to shared resources. There are many different floor control policies[7]. In Figure 2 we specify a centralized policy. There are three roles. The floor moderator role (line 8-34) controls who can obtain the floor at any time. A floor aspirant (line 36-60) is a participant who needs to apply for the floor from the moderator. And the floor holder (line 62-63) is the participant who currently holds the floor. At one time only one participant can be the moderator and only one can be the floor holder. There are no constraints on how many participants can take the aspirant role concurrently.
As is shown in Figure 3, participants in the floor moderator and aspirant roles use their corresponding tools (or graphical user interface, GUI) to interact with each other through the cocavms. The tools are connected to the cocavms by channels named local-in and local-out respectively. And all the cocavms are connected by a channel remote. The moderator tool expects two commands from the cocavm: one to request the floor, and the other to notify the user to whom the floor is granted when a coordination decision is made. It sends three commands to cocavm: one to grant the floor to a given participant, one to deny a floor request, and the other to revoke the floor from the current floor holder. The aspirant tool sends two commands to the cocavm: one to request the floor, and the other releases the floor. Messages from cocavm to the aspirant tool are grant, to notify the aspirant to whom the floor is granted, and deny, to report that the floor request is denied.
In Figure 2, when an aspirant tries to request the floor, the command arrives at aspirant cocavm's local-in gate (line 44). It is forwarded to the moderator via the ``remote'' channel (line 45). When this message arrives at the remote gate of the moderator (line 16), it is forwarded to the moderator tool (line 17), leaving the decision to the user.
When the participant in the moderator role decides to grant the floor to some participant (line 23), the message is multicast via the remote channel (line 24), meanwhile the moderator drops the holder role if she is currently in that role (line 25-26). When the participant cocavm receives the message which grants her the floor (line 51), the message is reported to the tool (line 52) and the floor holder role is taken (line 53).
To be concise, when a floor request is denied, the aspirant is notified (line 28-29, 58-59). When the current floor holder releases the floor, she drops the holder role and meanwhile multicasts the message so that the moderator assumes it (line 47-49, 19-21). And when the moderator decides to revoke the floor, the moderator assumes the holder role and the current floor holder drops it (line 31-33, 55-56).
The floor holder role is fluid. Anyone takes on this role when granted the floor by the moderator and drops it as a result of releasing the floor or when the floor is preemptively revoked. At this moment, there is no rule specified for the floor holder role. More in-depth discussion of this role resumes in section 5.
