In part one I showed a Windows application using Groove Web Services to talk (in a very minimal way) to Groove's collaborative workspace services. Note that this is how Groove File Sharing works too: in that case, yes, GFS is a shell extension which talks SOAP to the local Groove instance.

Now, how to link your application into Groove in such a way that

• your application's name appears in Groove's "create workspace" wizard;
• the app becomes a "telespace type", with its own icon for entries in Launchbar;
• when a user doubleclicks the Launchbar entry, your application is run;
• when you invite another user into the application/workspace, the app is installed and configured on their machine too.

Security

As a developer, you need to deal with some security intricacies to get this working. You gotta sign your code. There's a good reason for this: invitees into your workspace will get a copy of your executable code running on their machine, and they (or their company policy) need to decide whether that's allowed. This permission is achieved with signed code, and Groove enterprise groups can set up policies which allow or deny particular signatures by default.

To sign code, there's a utility OSDSigner.exe which is part of the Groove development kit. OSDSigner takes an OSD file (which we'll see shortly) and produces a version signed with the digital certificate you supply. These certs can be self-generated, or themselves signed by a higher authority (Verisign, etc).

OSD

If you've built Groove tools in the past, you'll have dealt with OSD: this is the file which lists all the components of a Groove solution, and their dependencies. The OSD file tells the Groove installer how to find each component (code, graphics, etc) and how to install them on the local machine.

The OSD for my minimal app has descriptions of: an "application descriptor" (XML); the actual application (.HTA, in this case) with instructions that it be installed in groove\bin\toolbin\xxx; a "create-space template" (CST), and the launchbar icons (JPG and a mask bitmap). All these files are hosted on a web server, so when any user needs to install -- for example, by being invited into a Minimal workspace -- they're available for download.

The signed OSD includes the path to each component file, and its filesize, and a cryptographic digest of the file contents. The digest (hash) ensures that you're installing the "real thing", not someone's 0wned version.

Bitmaps

Each launchbar entry for a Minimal workspace shows an icon (in this case, hexagram 32, Hêng. For no good reason...). The icon is in two parts: a 16-by-16 JPEG colour image, and a black-and-white mask bitmap (black where the colours should show).

The OSD installs my bitmaps into groove\data\ToolData\cabezal.com\Minimal\. The descriptor XML defines these images as the launchbar icon for my 'minimal' telespace-type.

CST

The CST file ("create-space template") tells Groove that my application should appear in the list of workspace types when a user creates a new workspace. It contains a <CreateTelespaceTemplate> element defining a Groove V3 telespace, containing a Files tool (which we're not using right now), and that the workspace type is "Minimal":

<!-- the telespace created by this template is of type 'Minimal' -->
<g:Type DisplayName="Minimal Workspace" Name="urn:cabezal.com:TelespaceTypes.Minimal"/>

Your application's workspace can contain any of the standard Groove tools, and/or custom-developed tools. But there's no user interface for any of these; users will never see the actual tools in the space, they'll only interact with your application. Your app might use a Files tool to store and share binary objects; or a Discussion tool, a calendar, or a Forms tool for record-oriented data. All those tools are easily accessible with Groove web services.

Descriptor

The application descriptor file actually defines your application type to Groove. It says that the telespace-type urn:cabezal.com:TelespaceTypes.Minimal has an icon; and a verb "Open" which runs my application code in cabezal.com\Minimal\Minimal.hta.

Injectable

Finally, I made an "injectable" (Minimal.GRV). If a user launches this GRV file, they'll install the application.

The install process

There are really two ways to have the app install. One is by launching the injectable; the other is to be invited into a Minimal workspace by another user. It's worth following the steps of that install process.

The workspace itself is some Groove secure storage (an .XSS file and transaction-log on disk); most of the workspace is XML documents in the XSS database. The "header" document tells Groove that this is a workspace of type urn:cabezal.com:TelespaceTypes.Minimal, and that its application descriptor is at the URL http://www.cabezal.com/Minimal/Minimal.osd?Package=com.cabezal.Minimal.cst&Version=1,0,0,0 (the ResourceURL in the TemplateDescriptor in the descriptor).

When an invitee installs the workspace, Groove checks the local "manifest" (an XML document listing all the components which are installed on the user's device) to see what to do with that telespace type. If the type name isn't registered yet, it looks up the ResourceURL. That pulls down some (signed) OSD, prompts the user whether to accept the code signature, and begins the download sequence which puts all the pieces on the local machine. When this install is done, the manifest gets updated, and then Groove knows how to open the telespace (using your application).

In summary...

Putting these pieces together is mostly a matter of search-and-replace in a provided sample. There are several files to deal with, but really all you need is to choose

• a name for your telespace-type,
• somewhere to host the files,
• where the app should be installed

Oh, and you gotta sign your code.