Uniting under Groove

Groove founder Ray Ozzie and his teams have always pretended to build application software. But what they have actually delivered are the operating systems of the future — years ahead of schedule.

The XML business Web is only now achieving the architecture that Lotus Notes laid down 15 years ago: message-oriented exchange of semistructured documents. As today's operating systems catch up with that paradigm, Ozzie is tackling the next set of challenges in Groove: drop-dead simple, secure collaboration, presence management, coordination of user and device identities, and ad-hoc group formation.

To make an omelet, you have to break eggs, and what Groove broke was compatibility with the e-mail infrastructure that serves (poorly) as our medium for team communication and as our distributed storage system. Groove also broke compatibility with the Web. Documents and messages in Groove's shared spaces had what looked like URLs, but those URLs didn't mean anything outside of Groove; they couldn't be bookmarked, shared, nor posted to the Web. Finally, Groove planted deep roots in Win32/COM, all but foreclosing non-Windows platform options.

They were hard choices with serious consequences, but there was no other way to make the omelet. What the Groove Workspace has delivered since Version 1.0, and steadily refined through Version 2.5 released last week, is a seamless and comprehensive environment for collaboration. It defines what Microsoft and Apple will be lucky to achieve by 2006. When they get there, of course, they'll bring along everything Groove had to jettison in order to sprint to the finish line. Meanwhile, Groove's challenge is to reel in what was thrown overboard. The 2.5 release confronts that challenge.

For users of Version 2.5, the bridges that Groove has been building to Microsoft Outlook are fortified. In 2.1, you could capture an Outlook e-mail thread (with attachments) and send it to a Groove shared space, but it was only through a heavyweight operation that you could create a new shared space. In 2.5, you can inject the thread into an existing space, choose among multiple discussions in that space, and include attachments with messages or send them to a file repository in the space. It's a dramatic improvement.

Entirely new is the ability to send Outlook contacts to Groove and to synchronize Groove and Outlook calendars. From Outlook, you can select one or more calendar items and inject them into a calendar in an existing shared space. Going the other way, a Groove calendar or meeting can now publish items to Outlook.

As always, the devil is in the details. My default view in the Outlook calendar is customized with a check box I use to tick off completed appointments. Groove didn't know that, so my default view filtered out the items injected by Groove. Happily, 2.5 cures these hiccups.

The Groove Web Services (GWS) integration technology (see "Extending Groove," Nov. 4, 2002, page 15), is now woven into the product. With GWS, accessing Groove's calendar data from C#, or Perl, or indeed any SOAP-aware language is straightforward. Now, if only Outlook's API was as easy to use.

Also new in the Professional Edition of 2.5 is two-way synchronization between a Groove shared space and a Microsoft SharePoint Team Services (STS) Web site. Using a separately licensed Groove toolset called the Groove Mobile Workspace for SharePoint, this bit of integration will appear more seamless to the STS user than it will to the Groove user.

An STS discussion reflected into Groove retains much of its native look and feel. That's disconcerting to the Groove user, who won't find the expected Response button. What's more, the Groove developer's shiny new GWS scripts won't find STS discussion data mapped to an accessible Groove discussion. The STS file repository is, however, mapped to a standard Groove file repository, and STS lists (events, tasks) map to Groove forms. From an STS perspective, Groove's superior collaboration features add value to the collaborative experience. STS is not very clever about tracking unread items, for example, except by means of the overkill solution of e-mail notification. Groove's change notification is more subtle and more effective.

Groove users also will appreciate the new capability of throttling downloads. Until now, a huge file dumped into a shared space amounted to a denial of service attack on users with slow links. It's now possible to set a file repository to receive metadata only, or to receive files only up to a specified size limit. One much-requested feature that still hasn't materialized is search. But thanks to GWS, shared-space data is now much more available to standard indexers.

For developers, 2.5 is a watershed. Groove has been an aggressive supporter of .Net, and in the new version of the Groove Developer Kit (GDK), the managed interfaces to Groove present a much larger surface. Indeed, Groove's encapsulation of its API in managed code arguably goes beyond anything Microsoft has done with its own products.

Last week also marked the production release of the Groove Toolkit for Visual Studio.Net. This plug-in simplifies the plumbing required to create a Groove tool — that is, an interactive tool that plugs into the Groove transceiver in the way a Java applet plugs in to the browser. There is much more to the art of Groove-tool construction than the new toolkit comprehends, and the task remains one that only a student of Groove's internal architecture can approach. Nevertheless, the Toolkit allowed me to create a simple transceiver-based widget with very little effort, a notable accomplishment.

For developers who aren't Groove-savvy but who can script Web services — nearly all of us — the official debut of GWS blows the doors wide open. The elegant SOAP encapsulation of the Groove API is incomplete, pending support in a later release for instant messaging and forms data. And only local clients can use the services. The 2.5 GDK previews remote access, but the 2.5 Workspace properly will not support that mode until a robust WS-Security solution can be hammered out.

In light of what GWS can accomplish, these are minor limitations. Now that local SOAP-aware scripts can read and write Groove contacts, calendars, discussions, and files, a world of opportunity has opened up. Using a preview of GWS, I scripted an agent that reads a Groove discussion and fetches the URLs mentioned there into a local file repository — which, of course, Groove automatically synchronized to all other instances of the shared space. The screen shot shows a Groove work space connected to my Radio UserLand Web log. Messages posted to one Groove discussion flow out to the blog, and news items fetched by Radio's RSS newsreader flow into Groove.

That's the ticket! Until now, you had to step out of the mainstream to take advantage of Groove's advanced collaboration technology.

Finally, we can have our cake and eat it too.