Session – Live Services: What I Learned Building My First Mesh Application

PDC 2008, Day #2, Session #1, 45 mins

Don Gillett

In my next session, Don Gillett explained how he wrote one of the first Live Mesh applications.  Jot is a little note-taking application that allows synchronizing simple lists across instances running on a PC, a phone, or as a “Mesh application” running in your web browser.

Mesh is all about data synchronization and Jot demonstrates how this works.  To start with, the following preconditions must all be set up:

  • User has created a Live Mesh account  (this is free and comes with a free/default amount of storage)
  • Jot has been installed to the PC and the phone
  • Jot has been installed in the Mesh desktop as a “Mesh application”

At this point, Jot will be able to take advantage of the Mesh platform to automatically synchronize its lists with all three endpoints.

Here’s one possible scenario:

  • John is at home, fires up Jot on his PC and adds “toilet paper” to the “Groceries” list in Jot
  • Data is automatically synchronized to the other devices in the Mesh—Jot running on the Mesh desktop and John’s wife’s phone
  • John’s wife stops at the grocery store on the way home, fires up Jot on her phone and gets the current grocery list, which now includes toilet paper

Jot is a very simple application, but it demonstrates the basics of how the Mesh platform works.  It’s primary goal is to synchronize data across multiple devices.

Out of the box, you can synchronize data without creating or running Mesh applications.  You just create a data folder up on the Mesh desktop and then set it up to synchronize on the desired devices.  Changes made to files in the corresponding folders on any of the devices will be automatically pushed out to the other devices, as well as to the folder on the Mesh desktop.

In this out-of-the-box data synch scenario, because the data lives in the Mesh desktop, this supports two main things:

  • Data is always being backed up “to the cloud” because it’s stored in the Mesh
  • You can access the data from any public web access point by simply going to the Mesh web site

Writing Your Own Mesh-Enabled Application

Applications written to support Mesh can take advantage of this cross-device synchronization, but only for users who have signed up for a Live Mesh account.

Because this technology is useful only for users who are using Mesh, it remains to be seen how widespread it will be.  If Live Services and Live Mesh aren’t widely adopted, the ecosystem for Mesh applications will be equally limited.

But if do you write an application targeted at Mesh users, the API for subscribing to and publishing Mesh data is very easy to use.  It is simply another .NET namespace that you can get at.  And if you’re writing non-.NET applications, all of the same functionality is available through HTTP, using a REST interface.

What Types of Data Can You Synchronize?

It’s important to remember the Mesh applications aren’t just limited to accessing shared files in shared folders.  Every Mesh application can basically be thought of as a custom data provider and data consumer.  This means two things:

  • It can serve data up to the mesh in any format desired (not just files)
  • That format is understood by the same app running on other devices

As an example, your Mesh application might serve up metadata about files, the files themselves, and combine it with other data local to that device.

The Data Model

Don talked about the underlying data model that your application uses when publishing or consuming data.  It looks something like this:

Mesh Objects

Data Feeds

Data Entries — optionally pointing to Enclosures

Mesh Objects are the top-level shareable units that your Mesh application traffics in.  They can contain one or more Data Feeds.  If they are too large, synchronization will be too costly, because they will change too often.  If they are too small, or fine-grained, users may get shared data that is incomplete.  What’s important is that a Mesh application gets to decide what data units it wants to serve up to the mesh.

Data Feeds represent a collection of data.

Data Entries are the individual chunks of data within a Data Feed.  Each is uniquely identified.  These are the smallest logical storage units and the chunks that will be synchronized using the underlying synchronization technology.

Enclosures are used when your data grows too large to store directly in an text-based feed.  They are owned by and pointed to by an associated Data Entry.  Media files are an example of data that would be stored in an Enclosure, rather in the Data Entry itself.

The Evolution of a Meshified Application

Don presented a nice plan for how you might start with a simple application and then work towards making it a fully Mesh-aware application:

  1. Persist (read/write) data to a local file
  2. Read/write data from/to a local DataFeed object
  3. Utilize FeedSync to read/write your data from/to the Mesh “cloud”

Don then walked through an example, building a tiny application that would synch up a list of simple “checklist” objects, containing just a string and an IsChecked Boolean.

Final Thoughts

Don mentioned additional Live Services APIs that your application can take advantage of, in addition to data synchronization:

  • Live ID
  • Authentication
  • Contact lists
  • News Feeds  (who is changing what in Mesh)

He also mentioned a couple of tools that are very useful when writing/debugging Mesh applications:

  • Resource Model Browser  (available in the Live Framework SDK)
  • Fiddler 2, third-party web traffic logger, from

2 thoughts on “Session – Live Services: What I Learned Building My First Mesh Application

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s