sticklebackplastic.com

Scott’s Weekly Source Code just looked at handling single instance applications using Visual Basic’s built in support. Rather handy, and desperately easy.

But it’s not how the shell does it.

Windows already has a defined way to handle this. Historically, this was DDE, which involved broadcasting Windows messages to initiate a DDE conversation. Naturally not the best performing option (ever wonder why the IE options are so slow at closing? They broadcast the options change notification to all windows). Command line args are limited in length, and you've got the added cost of creating a new process for each new file to be passed through.

So, in Windows XP and later, Microsoft added support for registering your application as a COM IDropTarget for the file type. When the shell wants to send you some files, it creates an instance of the COM object and passes it an IDataObject that represents the shell items for the files. In fact, because it’s giving you shell items, you’re not limited to files, but can now accept anything that can be represented in the shell’s namespace – printers, files within zips, any other virtual item. Try that with your command line args.

Implementing it is, well, what you’d expect from COM.

You can, if you’re feeling a bit daft, implement an in-process COM object, get your dll loaded into explorer and perform your own inter process communication with your app. Kinda defeats the point, though.

Or, more appropriately, you can register your application as the out of process COM server for the object. And then you need to implement the standard COM goo of registering a class factory with CoRegisterObject, and dishing out your IDropTarget when asked for it.

The shell calls your IDropTarget and passes in the parameters. So it all happens in your first instance.

And there's the subtle difference - it's less about single instance applications, and more about passing data through to the currently running app. Almost the same thing, but not quite.

Now, this method isn't perfect - it's no good if you just double click the executable again, or call it on the command line. And it's not terribly useful if you want to pass arbitrary data through (a command line arg saying "stop").

That said, there's nothing stopping your second instance passing through a custom IDataObject data format to the existing IDropTarget...

So you can get single instance working with this method, and getting shell multi-select verb support for free can be useful, too.

As ever, MSDN has the skinny.

Now, if only there were some C# code. After all, who’d want to use a Visual Basic dll that already solved the problem?

And I mean that in a good way.

WinFS was a fantastic concept. Complicated and grandiose, but quite clearly revolutionary.

The basic promise of WinFS was this: It was a general purpose data store all your data.

It promised a number of interesting end-user features. Firstly, data could be stored as structured entities directly in the database. Or you could keep the data in files just like you’ve always done and add the files into WinFS. Structured data would be extracted out and promoted into the database. Changes would be pushed back down into the file. And you could access the file directly, too, using plain old Win32 files (via some network redirector magic that SqlServer 2008 appears to have picked up – and this is where the confusion with WinFS being a filesystem comes from – the lines are certainly blurred here). It was all fully searchable and supported a synchronisation story.

Jon Udell (also a long time fan of WinFS) recently published a great interview with Microsoft’s Quentin Clark entitled “Where is WinFS now?” which is well worth a listen/read. Apparently, large portions of the technology have either shipped or are coming soon.

But bizarrely, most of it has ended up server-side.

So, let’s look at the client-side piece.

Search is done, although it’s arguably missing the first class relationships (I can search for all photos on a certain date, but not for all photos for a given persons birthday).

Common schema for the structured data is still MIA.

And synchronisation, ah yes. This was a big piece of WinFS, and is now also shipping separately:

“As they realized they were onto something, they started to fork out a componentized version of it that's now finding its way into a bunch of Microsoft products. The official branding is Microsoft Sync Framework. I think they're on target for shipping it in six different products, and for embedding it all over the place.”

The Sync Framework? The one that contains FeedSync? The protocol that powers Live Mesh? Yep.

Live Mesh provides synchronisation, just like WinFS. It enables storing structured data as custom items in a feed. Or you can store metadata about a file, with the files treated as enclosures and sitting in the local filesystem. Couple that with Vista’s (or is it Windows Search’s) Property System, and you’ve got your read/write file metadata.

And it has an API that allows any application to read or write to it.

In other words, Live Mesh is the global, shared data store that WinFS was aiming for.

It’s still missing the common schema, and as of today, Windows Search knows nothing about it (although that would be a great project to write) but frankly, that’s the icing on the cake. Every application needs to store data, and every application invents their own way (xml files, databases, zip archives). Every application is a data silo. A global data store like WinFS could crack that wide open.

And that’s a good thing.

Firstly, I’d just like to point out that I’m on the train. And on the Internet. The modern world continues to amaze and bedazzle me.

But what I really wanted to talk about was Live Mesh. I’ve finally got my invite (thought not through www.sharemesh.com surprisingly), installed it, played with it, and yes, it works lovely. It’s all file-syncing goodness. It’s all, well, it’s all a little bit underwhelming actually. It’s just not terribly exciting.

And then I watched the Channel 9 video with Ori Amiga on programming Live Mesh, and it blew my head off. The potential here is really powerful stuff. It’s a platform, and you’ve got several ways of working with it:

1. Just use the file system, and let Live Mesh worry about the synchronisation. You can make the minimum of changes to your application (perhaps add a file watcher) and still enable collaborative working.
2. Query Live Mesh via a REST interface – http to the Live Mesh service. And now you can store your data in a more structured manner, directly within Mesh. Partition your data up into Atom feed entries, and Bob’s your uncle.
3. Query Live Mesh via a REST interface on your desktop. This is a killer. You can make exactly the same http calls as you would to the Live Mesh service, but they are all non-network calls of the Mesh Operating Environment (cutely known as MOE) that runs locally on your machine, and which has all of the data of the online service locally, because, hey, that’s what Live Mesh does. And any changes you make to your local data store are automatically replicated up to the cloud.

The really big thing that hit me during this was the idea that Live Mesh can now be a generic application data store, shared by all local applications. We’ve seen this idea before. Well, nearly seen it. I’m going to come back to this.

And then, of course, Apple announce Mobile Me, which is, yep, a synchronisation platform. It’s the typical story; Microsoft announce a grand new vision to build a fantastic generic platform, and along comes Apple (or someone) and simply releases the working end application – something that just does the job.

And Mobile Me is very similar in terms of features. It does the whole sync thing – mail, contacts, calendar, photos, files, bookmarks, system (Mac) preferences, cross platform and phone (iPhone) – everything that Microsoft have promised, if not delivered.

So does that mean Live Mesh isn’t important?

Well, we’ll see. But I think Live Mesh has an edge – and that’s the API. It’s a platform, not an application. And by enabling developers to create applications with built-in cloud storage, personal synchronisation, collaborative working, structured data shared between local apps (I love this one), or devices that are actually online services such as Flickr or Facebook, well, they might just be on to something.

(And I’m no longer on the train. Mobile broadband modem died. It would appear that the modern world is not quite as amazing and bedazzling as I’d thought.)

Are you tired of never knowing which way up you insert a USB cable? Do you always need several attempt before you can plug it in? Want to know how to get it right first time?

Based on the empirical evidence of a total of 3 cables, I can say, with some conviction, that a USB cable is always plugged in with the USB logo facing up.

Indeed, Wikipedia, from whence I shamelessly stole this picture, backs up my, um, research, with this tidbit on the topic of usability:

It is not obvious at a glance to the inexperienced user (or to a user without sight of the installation) which way around the connector goes, so it is often necessary to try both ways. More often than not, however, the side of the connector with the "trident" logo is the top.

Shame USB drives don’t have the logo on them. I guess I’ll still have to get it wrong, swear and turn it over before using those.

Turns out, my expensive, stupidly big laptop doesn’t have a context menu key. You know, one of these:

Now, I’m kind of used to the fact that laptop keyboards layouts are implemented with random number generators, and have pretty much resigned myself to the muscle memory stutter when trying to hit end, home or page up and page down on any particular machine, but to take away my context menu key is just rude.

Especially when they’ve bothered to include a number pad. I’ve already got one set of numbers, thanks.

It’s taken me over a week to find it on my work Dell laptop – head top right then turn left four or five buttons. But it’s completely MIA on my new machine. (But if you use Fn + End, it opens calculator. I have no idea why.)

Fortunately, Windows is smart enough to include a registry value to change the values sent to the system when you press specific keys. Don’t like your keyboard layout? Change it.

Of course, it’s in scary binary format, so download a program to help you. I used SharpKeys, but there are plenty of them out there – they don’t need to install, just to change a single registry value.

So now it was just a choice of which key to use. The closest in physical position was AltGr, which according to Wikipedia, is only useful for getting the Euro sign € and the pipe symbol ¦ on the UK keyboard, and guess what, Windows lets you use Ctrl + Left Alt instead of AltGr.

Which meant a quick map of Left Alt to the “Application” key and a logout later, and I’ve got a working context menu key. Another fine hack.

It might be worth having a bit of a mooch through the list of keys in this tool, though. You can map all sorts of keys to special functions like Media Up and Down, and yes, Calculator.

Of course, I could have just pressed Shift + F10.

It’s been a little while since I last posted. Well, not counting the two posts earlier today. And, admittedly, since Smallest Child was born, I’ve struggled to hit double-figures in a single month, and oh-my-god, I’m writing a meta-blogging post.

I always promised myself I wouldn’t blog about blogging, but you know what, I’ve been doing this for (very surprisingly) over 2 years now. So I think I’m entitled to the occasional self-indulgence. Feel free to wander off now – this post is going to be very light on techie stuff.

(My first post was 25 May 2006, not that you’d know if from the blog software I’m using – for some reason, the Posts Archive list starts in June 2006. This blog runs on Single User Blog, an Open Source project started by Mitch Denny that I had a lot of fun hacking on and learning asp.net 2 with. Of course, I never did have enough spare time to implement/fix everything I wanted to (such as conditional gets on the rss feed – ouch) and you know that when the creator of the platform abandons it, it’s time to move on. I’d love to write a new platform, WCF and LINQ based, but I don’t have the time, I wouldn’t finish it, and I think Minima has already done it, so I’ll probably be off to BlogEngine.net sometime soon. I just want to migrate without breaking anything.)

Anyway, there’s more interesting things to write about. Namely, a change of jobs. I’ve had exactly 3 jobs in the last 13 years. One year at a database solutions provider that went bankrupt. 5 years as a C/C++ cowboy developer at a company that creates a finite element analysis suite (and whose website is beautifully, wonderfully, still running on the same dev box, with the same university domain name). And 7 years at a rather large online bank.

And I’ve left. I’d reached the point where there wasn’t much else I felt I could get out of being there – I’d ticked all the boxes I’d wanted to tick. I was a Principal Developer, but had moved away from writing code. I’ve had a brilliant time there – it really was a great place to work (despite what we used to say. We weren’t happy unless we were complaining). I’ve learnt an awful lot, and I’ve shipped a lot of software (there are a number of really important pieces of architecture that I’ve had my hands on that I’ve really rather proud of).

Plus, my wife and I work for the same company, many miles from home. Putting 2 kids in the car for 2 hours a day is a bit rough. Plus First Born is starting pre-school soon, and the child care just doesn’t work out when we’re both working.

So here I am. In London, living away from home contracting. My wife’s also just handed her notice in, and it’s all change Chez Moi.

I’m currently working on a 6 month contract down in London for a rather well known media company, building the back end processing system for pushing TV programmes out onto the Internet. Cool. My contract is for me to be an Application Architect, but I’m kind of on secondment to this project right now, so I guess I’m a dev of some sort. But it’s really good. I’m 3 days in, and have already been pairing, writing test-driven code, and checking stuff in; I’ve been productive, which I was expecting so soon.

“Team Agile” as my ex-boss puts it. He’s not bitter.

But enough navel-gazing.

I’ve got me a new laptop, and quite clearly, my eyes are bigger than my belly. It’s a Dell Inspiron 1720. Yep. 17 inches of goodness. Er, screen. And that’s a whopping 1920 x 1200 resolution. I’m all awash with screen real estate right now; it’s lovely. And the 4 gig helps, too. Check it out:

This isn’t a laptop, it’s a desktop with a built in screen! It’s even got a numpad!

And it’s just as big and heavy.

Yeah, I’ve sacrificed some convenience for raw power. Oh well. I’ll get over it.

There’s a new test version of Windows Live Writer out, and amongst the changes is one to warm the cockles of my heart – they correctly register the Windows Search filter for .wpost files. Which means that post is now irrelevant.

Thanks guys.

nothing to see, move along.

Really.

(And this post is staying up, too. Think repaving a new laptop, copying over all your old Windows Live Writer posts only to find that if you edit one and try to publish and it just creates a new file and rather disappointingly even creates a new post, rather than just updating the old post. Time for another not-so-quick hack. Now, how do you do Structured Storage again?)

Speaking of data portability, and how Live Mesh plays with this, some of the big boys have recently made announcements - MySpace, Facebook and Google.

MySpace seems to be playing catch up and are announcing a REST API, initially restricted to a few partner sites. Perhaps the least impressive announcement, but the interesting part is the use of the OAuth standard for authentication.

Facebook then (a little too) hurriedly announced Facebook Connect, which seems to be a way for you to associate your profile with a third party site. That site then seems to get privileged access to the Facebook data.

Google announced Friend Connect, which is a complete sleight of hand trick. It's all about creating a social network at your site, but by hosting Google gadgets. One gadget is the master membership gadget, and all the others are OpenSocial gadgets that do "social" stuff. When you visit the site, you sign in to the membership gadget (via Google Accounts, Facebook, OpenID or AIM account). Then, the membership gadget lists all of your friends from these accounts that are also friends at the new site. The other gadgets provide the social element, such as comments.

So how do the big boys handle Data Portability? Well, poorly.

Surprisingly, MySpace is the most open. Facebook's offering definitely seems to be a step in the right direction, but appears to be limited to certain 3rd parties, and is entirely proprietary. But Google. Oh boy. They're not even trying. All of the data is stored in Google's silos. They aggregate data from other networks, but don't let any of it out - a proper roach motel. Their social offering is all based on gadgets, and the hosting site doesn't see any of the social data.

Charitably, you can view Google's play as not being about data portability, but about enabling sites to easily add a social element - playing to the Long Tail of sites wanting a social element without having to build up the number of members required to make a successful social site.

Of course, the fun only starts there. Facebook have banned Google's Friend Connect from accessing the Facebook API, because they've violated the terms and conditions of the service (more from TechCrunch and a detailed view from Google). It would be very easy to be snarky here and ask how committed Facebook is to Data Portability...

(And Dare makes a welcome return to blogging with a great post about this.)

But it does raise a very interesting question that Live Mesh (which might be able to sidestep these portability issues) doesn't address - ownership of data. DataPortability.org's Chris Saad has an interesting view on this in his blog post "Forget Facebook".

My address book is my own. When you email me, or when you communicate with me, you are revealing something about yourself. You define a social contract with me that means that I can use your information to contact you whenever and however I like - I could even re-purpose my address book for all manor of other things.

If, however, you violate that trust, either directly or indirectly, you break the social contract and I will tend to not deal with you again. We can not perfectly engineer these sorts of contracts into systems - we can try, but in the end social behavior will be the last mile in enforcing user rights.

And I think this nails it. Unless you want one way communication, you have to share information. You need to trust who you're sharing that information with, just like we do in the Real World with telephone numbers and addresses. Any technological barrier we put in place here is just Rights Management, and we all know how well that's worked out for DRM.

Live Mesh has been out for a little while now, and while I'm still waiting for my invite, I have been digging through the available blogs, documentation and videos.

Now. This is going to be a long post, because Mesh is kinda deep. You've been warned. Go and get a coffee.

Put simply, Live Mesh is a synchronisation platform. We've seen plenty of those before, even from Microsoft themselves (FolderShare, SyncToy), and the current user experience of sync-ing files and folders doesn't really distinguish itself from the other offerings. (DropBox is a beta application that is almost indistinguishable - with a good flash video intro). It might not be terribly remarkable, but it works, and it's definitely a useful tool as it stands. The platform is the best bit.

Let's try and describe what you get in as few words as possible.

A Mesh is made up of multiple devices. A device is really any kind of computing device. The Windows PC is currently the only one supported, but Mac and (Windows) mobile support is coming soon. You can create special "Live Folders" on your devices, and the contents of these are replicated to any or all of your devices. Any changes you make to any files in any folders on any device are replicated to all devices. So far so good.

There is a special device called Live Desktop. This is more than just another device, and is provided by Microsoft. Firstly, it's a device living in the cloud, and provides you with 5 gig of cloud based storage. Secondly, it's accessible via the browser (using a simulated desktop UI, complete with Explorer windows). Thirdly, it's really the coordinating service and notifies all the other devices when changes are made, so that they start updating their copies (future versions will apparently support a more peer-to-peer approach for this kind of thing), and it is instrumental in setting up a browser based (as in, ActiveX) remote desktop into your devices.

So we've got a platform that allows me to have my files locally, on any device I own. It also gives me access to those files remotely, via the cloud storage or via remote desktop. It's the Software + Services model, but larger. Instead of giving me access to my data from wherever I need it, it puts my data wherever I am. A subtle distinction, but incredibly significant when you start to consider things outside of the mesh I've described so far.

The synchronisation platform Microsoft have built is where things start to get fun. It's all built on feeds. You know, RSS and Atom. Everything that is a list is a feed - list of devices? Feed. List of folders to sync? Feed. List of files and folders in each folder? Feed. Each file's metadata is stored as the item entry of a feed, and the file itself is referenced as an enclosure. And then they layer FeedSync on top of the feed. FeedSync is Microsoft's extension to feeds to provide versioning, history and conflict detection (but not conflict resolution. I don't know how Mesh handles conflicts).

This is probably the masterstroke of the platform. They haven't just built a platform for synchronising files and folders, they've built a platform for synchronising feeds. And feeds can hold any kind of structured data. Contacts, bookmarks, comments, status updates, calendars, bank transaction data, you name it. And they've used existing, open data formats. The data is available from the cloud as Atom, RSS or JSON, via a REST interface, using the Atom Publishing Protocol. All the current industry darling buzzwords - everything to make life easy to make mash ups.

And (the SDK isn't yet available but I think this is how it's going to work) you can easily imagine a web site that talks to the Mesh cloud interface and gets (secure) access to your Mesh data. And your rich, desktop application can make the same requests of the cloud. And because it's all synced, your rich, desktop application could simply use the current device's local version of the data (using the same REST API, of course), enabling offline access. Software + Services and mash ups from the same interface.

With this in mind, it's easy to see how you would share content amongst friends - simply start synchronising a feed between the two of you. And this is exactly what happens with the current implementation. There's even a feed of activities performed against the data being shared, to which users can add comments.

So, let's run with this, and see what falls out.

Subscribe to Twitter. Subscribe to Facebook. Blogs. Del.icio.us. All of this data is now aggregated, just like FriendFeed.

Take a photo with your phone, that just happens to be a device in the mesh. It automatically gets included into the mesh and flows to all the devices that are sharing that data. Want to publish that photo to Flickr? Create Flickr as a device and it will automatically get published. Someone leaves a comment on Flickr, and since you've subscribed to the Flickr feed, that comment gets synchronised to all devices as metadata associated with the photo.

Generalise that a little. Imagine all of these social networks as devices. All of a sudden your problems with the Centralised Me disappear. You data still lives in the data silo of each social network, but each social network is an integral part of your mesh. You can share the items on your social network, or you can share them from your mesh. Data Portability is less of a problem, because your data doesn't need to be portable; your mesh is a superset of all of these silos.

Want more than the 5 gig of storage Microsoft gives you? Create a device that's backed by Amazon's S3. It's all just feeds and https. In fact, Microsoft are already planning to enable enterprises to replace Microsoft's cloud storage and store data internally.

Subscribe to a feed of bank transactions, using OAuth. Subscribe to all of your banks' feeds and you've got enough data to build a client side aggregator. If the web sites of all the banks can make use of the data in the Mesh (with appropriate security), then every bank has the ability to include aggregator functionality in their site, and they now have an incentive for providing the feed in the first place.

Of course, this is just speculative, but it's easy to see that there is a huge potential to this model. It all depends on how Microsoft handles it. There are several warning signs. Joel pinpoints them quite well in his post "Architecture astronauts take over". Microsoft are really hyping the future of the platform while the current application is not as exciting. (Dare Obasanjo offers a good reply to that post.) And it's still very Microsoft centric. Authentication happens with Windows Live ID, they maintain the index of which devices are in your mesh, and the Live Desktop plays that coordinating role in notifications. People didn't trust Hailstorm, or Passport; will they trust Live Mesh? Will Microsoft allow splitting up of those central services? Logging in via OpenID? Federating the cloud storage? Allowing people to create their own meshes which can interact with Live Mesh services? We'll know more in the Autumn, when Microsoft hold their Professional Developers Conference.

So that's Live Mesh. Boil it down, and it's a deceptively simple premise - it synchronises feeds. The power (and the potential for failure) is the promise that everything is consumable as a feed. Will that happen?