You have probably read or listened all the (maybe a bit vague) information about the Mesh Operating Environment (MOE): a platform that will allow multiple applications and devices to participate in the Live Mesh.
Let’s get to the more technical details now, and leave the end-user marketing to someone else .
At the core of Live Mesh is FeedSync, a public spec by Microsoft, evolved from the “old” days of SSE. It didn’t get its deserved attention IMO back in the day, even though you could put together the pieces from Ray’s announcement and later adoption by other products and figure out Live Mesh was coming sooner or later. Ed Jezierski got me interested in it WAY back, and as a result, I created the first open source implementation of the spec.
To understand its importance you need to first understand what FeedSync is. The most succinct definition I could come up with is:
FeedSync is a definition of a versioning header (or metadata) and its associated creation, update and deletion behavior as well as a generic conflict detection algorithm based on it, which can be attached to an arbitrary piece of data.
The interesting part of it, as you are probably realizing already, is NOT the XML microformat itself, or its representation in an RSS/Atom feed, but rather the behavior and semantics associated with it, which you can rely on to be present at compliant endpoints.
The specification defines the behavior for merging (arguably the most important one) data between two “feeds” (think of these as “streams of data with associated versioning header/metadata”) in a consistent manner. It’s two-way sync for the masses.
Of course, specs without implementations are seldom of any use. Microsoft is providing their own with the Microsoft Synchronization Framework (which does other things in addition to supporting FeedSync), and now Live Mesh. But nothing forbids the community from building compliant cross-platform open source alternative implementations.
Being an open source fan myself, and being lucky enough to work for an organization whose goal is to produce open source software to help in the humanitarian space, I’m glad to announce that we have already been working actively in this space, and we just released early versions of our ongoing projects at Google Code.
Mesh for X
Or Mesh4x for “short”, is an umbrella project by InSTEDD under which we’re producing Mesh4j and Mesh4n (Java and .NET respectively) versions of a unified implementation and library design/API for FeedSync synchronization between arbitrary repositories of data (i.e. databases, files, spreadsheets, etc.). We may very well come up with Mesh4py (Phyton), Mesh4r (Ruby) or whatever we or the community need to satisfy data synchronization scenarios.
The Mesh4n version is coming straight from its old place in CodePlex, but you expect it to evolve together with the Mesh4j version. Our goal is to keep feature-parity on both. This version of FeedSync for .NET is being used by Microsoft Humanitarian Systems (MHS) in Afganistan to synchronize disparate data sources in extreme and low connectivity conditions as mentioned by Ted Okada (i.e. to achieve two-way synchronization of disconnected Access databases, Excel files and plain RSS files on a pendrive, between any of them!).
At this time, both libraries provide the basic synchronization algorithm and Sync (metadata) data model, as well as the core interfaces to create your own repository adapters to expose data from arbitrary sources for FeedSync synchronization. We’ll be building concrete repository adapters during the next few weeks. The most interesting one for me is the Mobile repository, which should allow you to sync two repositories over cellphones, without cellphone internet connection or even a data plan (which needless to say is not very frequent in the under-developed or even developing world).
We’ll also be looking for refactoring opportunities to simplify certain scenarios and accomodate the future roadmap for FeedSync.
Some people have argued this is just another consumer-oriented Microsoft-thinghy that will hardly make a difference in anything. I believe that’s a mistake, as it’s ignoring the underpinning technology, the fact that it’s a public specification, and that it can be applied to really free the data once and for all, regardless of platform, application, format, language, etc. This is the very reason I’m not excited at all by all the Atom Publishing Protocolfuss that’s happeningthesedays. Web 2.0/AJAX + APP is SO client-server… but that’s for another post, another day.
Stay tunned as I’ll be posting more detailed (and practical) information about Mesh4x in the coming weeks, as well as the cool stuff we’re doing with InSTEDD as part of its goal of helping in the humanitarian space by applying technology.