Tom Coates is writing a series of pieces "arguing that the behaviour of an until-recently small group of digital music fans seemed to be now spreading into the mainstream"...

One of the first questions you have to ask yourself in any organic R&D role (which is I think how I'd characterise what I do) is am I a freak or am I an early adopter? You have to have some sense of how much your instincts and excitements are in tune with real people in the world because otherwise you cannot possibly evaluate how those people might respond to the products, concepts or propositions that you think are exciting. In this case, it's becoming fairly clear that people who are listening to digital music and in connected ways are very definitely more like early adopters than they are freaks. They're pointing in roughly the right direction.

(The really interesting questions don't get asked yet. Of all the songs in the world, inclusing the hundred new today, which do you want to listen to right now, and why?)

Recent, recommended, reading: "The curious incident of the dog in the night-time", by Mark Haddon. Caveat lector: it's very English, and contains some of the ripest four-letter words in existence (but in totally realistic context). Here's a taster:

And one day Julie sat down at a desk next to me and put a tube of Smarties on the desk, and she said, 'Christopher, what do you think is in here?'
And I said, 'Smarties.'
Then she took the top off the Smarties tube and turned it upside down and a little red pencil came out and she laughed and said, 'It's not Smarties, it's a pencil.'
Then she put the little red pencil back inside the Smarties tube and put the top back on.
Then she said, 'If your Mummy came in now, and we asked her what was inside the Smarties tube, what do you think she would say?', because I used to call Mother Mummy then, not Mother.
And I said, 'A pencil.'

Twice tonight, my machine clock suddenly went forward to March 2024. What's up?

Groove V3.0 is shipping. Congratulations to the team!

Bo is blogging. Stylish!

Getting close now: Groove Virtual Office 3.0 will be released next week...

Barb Darrow at CRN has an interesting interview with Ray:

Ozzie: Most significant is probably the usability of the product. We've done tremendous rework of the interface o make it much easier and lower-training cost to get people up to speed and performance is significantly improved. The other major investment is Groove File Sharing... every Windows folder now has a Groove button in it and if you press it, you turn that folder into a workspace that shares that folder with other people inside or outside the company, puts red marks on files, lets you have chats and conversations privately within that folder, it projects all the platform capabilities of Groove right into the file system. It lets people share folders across all their computers, whether at home or at work and between people who are working together.

For both Mac and Linux, it's not a religious issue. When a customer says 'I have a big order and want to place it but I'll make it contingent on the availability of a Linux or Mac version' we'll be coding away.

To recap,

• First I talked about GFS, the very useful folder-synchronization feature in Groove V3. This puts Groove's collaborative-workspace features right into the Windows shell. Folders are workspaces.
  
• AppLauncher (part one) describes how to build the same type of integration into Any Windows App, so that YourApp has a Groove workspace underneath. The application is launched from Groove with a commandline saying how to access the workspace's services.
  
• AppLauncher (part two) shows the glue which binds "your application" into the Groove user experience.

Existing applications -- anything from off-the-shelf software to custom line-of-business apps -- can easily take advantage of Groove's collaborative services. They can inherit an easy, secure, robust, decentralized way to share state between several people in a "workspace". For example, if you have built a .NET (WinForms) application for a customer-support process, which accesses an Oracle back-end, this app can also be used in small groups with a "shared context".

You might use Groove's workspace services simply to store local data securely.

Or, more interestingly, you might put work-in-progress documents into a Groove workspace ("underneath" your app) so that multiple users can work with them as part of your larger process. Because the workspace is Groove, those users wouldn't even need to be online to have access to the shared data. They wouldn't necessarily even need to be in the same company.

So, that customer-service application might front-end Oracle... but you might want to invite the customer into your instance of the application to make a shared place for interaction. They wouldn't see the Oracle database, but your application might push some of the relevant status documents and data into the Groove distributed storage...

New applications can be built on the Groove platform without any really specialized knowledge. There's a very "regular" web-services API to communicate with Groove; the rest of the app is up to you. (Personally, I want to build some games...!)

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.

Here's a first, minimal example of the "app-launcher" extension mechanism for Groove V3. As I hinted earlier, this is a straightforward framework that lets developers build applications integrating really nicely with the Groove launchbar and with Groove's decentralized platform -- consistent, secure, shared data models; awareness, presence, instant messaging -- without requiring the application to "live in Groove".

In fact, it's possible to have a single version of your app which "knows" when it's being run from a Groove context, by having Groove launch it with a special set of commandline parameters, and use that to switch on whatever collaborative features might be important (without preventing its use as a standalone app).

The standard commandline, though, is what gives your app its context. Remember, in this application model your program "has" a Groove workspace "underneath" it, and can use that workspace to share with other instances of the program running at other users' machines. Each member of the workspace (ie. anyone you invited, just as with any Groove space) has a synchronized copy of the data in the space. But when they open the workspace, instead of the Groove user interface, your application is launched.

So the two basic commandline parameters are: the "IdentityURL" of the current user, and the URI of the current workspace. [There's a third -- the verb with which the application was launched -- but in my minimal sample I've no need to use that]. The URI is the Groove Web Services address of the workspace: the space can be accessed by POSTing SOAP messages to that identifier.

So, here's my sample code. I've called it "Minimal". There's not even any compiled code there; the application is an HTA (DHTML and JavaScript). If you download the zip and look at the .HTA file with a text editor, you'll see how the application works. (More on that below the fold here).

The app has its own icon in launchbar:

although maybe the user interface of my application could use some work:

Still to come in the next instalment: some words about the half-dozen support files other than the HTA. They're fairly intricate, but not scary. (I made mine almost entirely by search-and-replace from the AppLauncher sample which ships with the v3 Groove developer kit).

One great feature of Groove V3 is folder-synchronization workspaces. These are just Windows folders -- on your desktop, or anywhere else on the filesystem -- which are also Groove workspaces.

On the one hand, they behave like Windows folders. You can open them, drop files into them, doubleclick files to launch them, and so on.

And on the other hand, they behave like Groove workspaces. You can invite people to them; those invitees get their own synchronized copy. Any changes in your local version are securely shared with the other members (and you don't need to be online at the same time, it just works). Anything they do, you see. New or changed items in the workspace show an "unread" flag. Groove pops up a little notifier when there's new content, or when people enter the workspace. You can even control whether you download all files automatically, or you want to manually download files over a certain size when it's most convenient. There's a little sidebar showing whether the members of the space are online. Doubleclick one of the members to send them an instant message. Open the chat pane and chat with them.

These workspaces are listed on the Groove launchbar, just like "normal" Groove spaces. Doubleclick the launchbar entry, and the folder opens.

So, this is all pretty awesome. File-sharing workspaces are great for working on documents in a team; also just for sharing current versions of files between, say, your work and home machines.

It's also a really significant view of what Groove's platform services are all about. We took a familiar user environment - Explorer - and outfitted it with Grooviness, to create a seamlessly shared environment which is at the same time completely familiar and normal, yet also enabled for collaborative groups to work in.

Now you can do this too. (By you, I mean you-if-you-build-software-of-any-sort). The kind of extensions to Explorer are available to YourApplication really transparently and quite easily. The V3 GDK includes a sample called "AppLauncher", which I'll talk about in some detail next.

Wow! This weblog is three years old!

To celebrate that, I'll share with you some of the groove sourcecode. This is my checkin to the build today:

115a116
> CollectGarbage();

Not bad for a day's work, huh?