I recently met with Groove's Jack Ozzie and Michael Helfrich. Jack is a co-founder and VP, development; Michael is VP, applied technology. The subject, of course, was the forthcoming V3 of Groove, a product I first saw in beta four years ago this spring. We had a wide-ranging discussion; here are some of the key takeaway points.
Sayonara, top-to-bottom XML I don't believe that I pay a performance penalty for using XML, and depending on how you use XML, you may not believe that you do either. But don't tell that to Jack Ozzie. The original architectural pillars of Groove were COM, for software extensibility, and XML, for data extensibility. In V3 the internal XML datastore switches over to a binary record-oriented database.
You can't argue with results: after beating his brains out for a couple of years, Jack can finally point to a noticeable speedup in an app that has historically struggled even on modern hardware. The downside? Debugging. It was great to be able to look at an internal Groove transaction and simply be able to read it, Jack says, and now he can't. Hey, you've got to break some eggs to make an omelette.
I'm sure Groove has made the right choice here. Still, it's troubling if you believe -- as I do -- that a high-performance XML database ought to be a core piece of client infrastructure. Groove's original XML database vision was probably too forward-looking. Version 1.0 was effectively done, for example, by the time the ink was dry on the XPath specification. XML storage technology didn't then support what Groove wanted to do. Arguably it still may not. We don't yet know what Chandler will be able to achieve with Berkeley DB XML. Meanwhile WinFS is turning out to be less like the XML database I imagined, and more like a record-oriented (or rather, CLR-object-oriented) database.
So how do we resolve the impedance mismatch between our desktop storage engines -- the file system, conventional databases -- and the XML content model that is increasingly the choice of desktop applications? I'm still looking for the solution to this puzzle.
Groove and .NET The managed-code interface to Groove gets an overhaul in V3 but the core product itself does not rely on .NET. Not because Groove's developers wouldn't like to use .NET. They very much would, Jack says. But rather because the already steep ante -- Groove's a 10MB download -- looks even steeper when you pile on a 20MB .NET download. This isn't news, just another datapoint, but every time I hear this it tells me two things. The CLR and .NET Framework aren't yet infrastructure that a mainstream Windows developer can take for granted. But when that finally becomes true, a whole lot of pent-up developer demand for .NET services will be released.
Python? During a demo of the V3 forms builder, which gains some nice yardage on the previous version, I noted that the scripting languages supported are VBScript and JavaScript. Hmm, thought I. Is this thing an ActiveX Scripting Host? And if so, can I plug in another scripting engine that works in that environment, say Python? The answers were "Yes" and "Don't see why not, we'll get back to you."
Groove Web services The Web services stuff that I explored a while ago has matured, and is baked into the product. Groove V3 comes up listening for SOAP calls from localhost, and can be configured to listen for SOAP calls from remote nodes.
The good news: in addition to using forms, you can write scripts that reach through the Web services layer to find things in Groove spaces. The bad news: you'll have to, there's still no built-in search capability.
Challenges
Early reviews of the 3.0 beta have showered praise on the product's revamped UI, and I'll add mine: it's cleaner and better optimized for common tasks. There remain challenges. Groove is a holistic solution that shares idioms with both Windows and the web in ways that seem familiar, but sometimes aren't. In the Groove "Files Tool," for example, you're shown what looks like a file in a folder, but is actually an encrypted and synchronized Groove object. Double-clicking the file opens it into its default editor, which may (or may not) reveal the fact that the file has been decrypted to your local temporary directory for viewing and editing. Quitting can result in a two-step tango. First the editor asks if you want to save. Then Groove, detecting changes, asks again: "Do you want to save?" It's the classic dilemma of every document manager that hooks File Open and File Save gets in between apps and storage in order to add value. In Groove's case, that value is considerable: automatic secure synchronization, and change notification, across all instances of a shared space. But until and unless a more intimate relationship can be forged between Groove's secure/transacted/synchronized storage and the OS-level storage APIs that applications expect to see, there's just no way to make this seamless.
Groove's use of web metaphors raises other challenges. For example, navigation from tool to tool within a Groove space uses browser-like back/forward controls. But in a space that includes an embedded browser, you end up with two separate sets of back/forward controls. Groove's hyperlinking is also similar-yet-different. Depending on the Groove tool you're in, you may be able to form a link to a record, a view, or the tool itself. For which audience is the link relevant? It depends. Members of the space that contains the tool can jump to it from a link pasted into, say, a chat window or discussion. The same link pasted into another space may or may not be accessible to everybody, depending on who's also joined to the target space. Can the link point into Groove from the outside, say from an intranet web page? In theory yes, though I'd be surprised if anyone has ever done it.
Groove's transacted/synchronized storage model envisions a species of applications that don't yet exist outside of Groove. Likewise its hyperlinking model envisions collaborative scenarios that don't yet flourish outside of Groove. Such applications and scenarios would present thorny usability challenges even if there were no legacy to consider, because the total experience is so different from what we're conditioned to expect. Of course there is a legacy. Reconciling it with Groove is incredibly hard, but there's been steady progress all along, and V3 is another big push forward.
Former URL: http://weblog.infoworld.com/udell/2004/05/04.html#a988