XML not all that it's cracked up to be? (Breaking eggs for omelettes)

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.

Maybe COM is to blame or some other implementation flaw. Plenty of binary storage formats are able to be simply inspected. (Jon Udell's interview with the Groove team.)

In the Groove "Files Tool,"... 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 in order to add value... there's just no way to make this seamless.

Hmm. Doesn't editing an Office document in Share Point provide this seamless interface? Does the public Windows API not have these features for any application's Open and Save events? Sigh.