Following up on this post, I thought I’d see if I could share some files through the Live Mesh and perhaps move on from writing a console application.

Photos seem to be the most obvious choice so I thought I’d start there.

What I figured was that I would just want a very simple way of storing the data so I figured I’d use a single MeshObject with a single DataFeed hanging off it and into that DataFeed I would add my photos.

I also figured that I’d want to work against the Local Live Operating Environment all the time because I don’t really want to have to figure out network status and connect/disconnect from the Cloud Live Operating Environment – that’s too complex and seems unncessary to me unless I’m running in a situation where I don’t expect the user to have installed the Local Live Operating Environment ( i.e. the “Live Framework Client” ).

So…easy. Or not 🙂

What I got stuck with was how to deal with the various interleavings of synchronisation. Imagine the scenario;

1. My application runs up on Machine1 against the Local LOE.
2. My application tests to see if its MeshObject has been created or not. If not, it creates it (MO-1) and adds a DataFeed to it.
3. My application runs up on Machine2 against the Local LOE.
4. My application tests to see if its MeshObject has been created or not. If not, it creates it (MO-2) and adds a DataFeed to it.
5. The synchronisation stuff kicks in and synchronises MO-1 to Machine2 and MO-2 to Machine1.

and so on.

My basic problem is that if I choose to work against the Local LOE then how can I definitively create the single MeshObject that I want to store all my photo data? I’m not sure how I differentiate between the situation where;

1. The application has never run before and so the MeshObject genuiely needs to be created.
2. The application has run before but not on this machine and so might be for the Local LOE to pick up and sync the MeshObject from another machine.

In the end, I decided it was futile to try and so what I went with was;

1. When the application runs up, it checks to see if it can find any (or many) of my MeshObjects by name.
2. If it does, it syncs up to the DataFeeds offered by all of them and it also syncs up a change notification in case any more arrive whilst it is running.
3. If it does not, it creates its own MeshObject and ensures that it is mapped to all devices that it can find.

So, it feels like if I had 100 machines and I ran the application on all of them at the same time I’d probably end up with 100 MeshObjects whereas if I ran it on one machine and then waited a while before running it on the other 99 then I guess I’d hope to end up with just 1 MeshObject which would have sync’d to the other machines.

At least – that’s what I was thinking about when I was trying to write this code. Whether that’s what I actually came up with ( and whether it’s a sensible thing to do in the first place ) is another matter altogether 🙂

In many ways, the code is similar to the code I had on the previous blog posting except that it tries to deal with the problem I’ve just outlined and it stores thumbnails of images into the DataFeed rather than just storing a single stream but I’ll not paste large chunks of the code into this post.

Here’s the app running on my local machine and on a remote desktop sitting behind it – the UI is just a ListBox and 3 buttons;

I’ve uploaded the code so you can have a play with it if you like or maybe it’ll provide the basis for something you’re doing. Bear in mind that this code is pretty rough as I’m just using it to try and figure out what the Mesh can/can’t do for me via this SDK at this point.

Here’s the download link for the project ( you’ll need the Live Framework SDK ). Some other things that interest me around this are how I can publish arbitrary data to the Mesh ( I think I read about being able to attach an arbitrary, serializable .NET object to a DataFeed somewhere ) and also how I go from an installed client application like I’ve got at the moment to a Mesh-enabled application.