Microsoft Office Groove 2007 Workspace Replication Upon Acceptance of Invitation

This blog explains how a Groove 2007 client behaves differently from a Groove 3.x client on the replication of a workspace.

Upon a client's acceptance of a Groove workspace invitation, the current content of the workspace is replicated via a Groove cloud to the client's end. I am referring a Groove cloud as the network infrastructure required to establish Groove connectivity between two Groove clients either directly or with Groove Server Relay. This is whenevery workspace member gets an initial copy of a workspace replicated to ones local Groove device when first joining a workspace. Where a new workspace member to acquire an initial copy of a workspace in Groove 2007 is different form that in Groove 3.x however.

Groove 2007 has a flexible scheme of workspace replication. (See the Groove 2007 protocol slide.) All the members who were online at the time when a workspace invitation was created can carry out workspace replication. For instance, let's assume when Alice created a workspace invitation using Groove 2007 both Bob and Chuck were online as well. Alice subsequently sent the invitation to Dee via Groove infrastructure as show in the screen capture. In this scenario, when Dee accepts the workspace invitation sent from Alice, either one of the three (namely Alice, Bob, and Chuck) can carry out the workspace replication to Dee's Groove device since all 3 were online when the invitation was created. In other words, after sent out the invitation, if Alice becomes offline, the replication can still proceed with a connection between Bob and Dee, or Chuck and Dee if available. When Bob or Chuck is sending a copy of the workspace to Dee, a Groove alert will appear on the sending Groove device indicating a workspace is being sent on Alice's behalf. Notice the invitation needs to be sent via Groove infrastructure. In other words, one who is invited has a Groove identity already (so the invited's public key is readily available), also the invitation must not require confirmation so no user intervention is necessary and all operations can be fully automated. From Groove PKI's perspective, these requirements make sense and are obvious.

In Groove 3.x, on the other hand, a client upon accepting an invitation will acquire a copy of the workspace from the one who created the invitation. (See the Groove v.3 protocol slide.)Consider the scenario. If Peter created a workspace invitation using Groove v3.x and sent the invitation to Rita. Peter's copy of the workspace becomes the source of the content to be replicated to Rita's Groove device once Rita accepts the invitation. If Peter is offline when the invitation is processed by Rita, Groove can not proceed with the workspace replication since the source of the content (i.e. the local copy of workspace associated with an invitation, here Peter's copy) is not available.

Notice there are triggers to default the workspace replication behaviors back to those in Groove v.3 . Some are briefly discussed earlier. Sending an invitation as a (grv) file, inviting via email, inviting to a v3.x workspace, and requiring acceptance confirmation are among those.  

Groove is a highly integrated solution and understanding the fundamentals is essential to appreciate how and oftentimes why Groove works in a particular way. For those who are interested, there is much readily available information included in my Groove resource page and some previous postings.