A few folks I’ve talked to in the Live Frameworks CTP forum or in email have expressed a little bit of confusion or a lot of surprise at what you can do with the Live Mesh platform and Live Frameworks. Let’s run through a few of scenarios to give you an idea of the breadth of options you have to leverage Live Mesh and Live Services in your applications.
First, let’s look at what kinds of applications can access user data stored in the user’s mesh (after user consent, of course):
- Silverlight mesh-enabled web apps
- Server-side web applications (Windows Azure, ASP.NET, Apache, PHP, etc)
- Cloud-based web services (Windows Azure, Amazon EC2, Google Apps, etc)
- Desktop .NET apps
- Win32 apps
- Win64 apps
- Linux apps
- Mac apps
- Mobile device apps
- Anything that can make HTTP requests, set HTTP request headers, and process XML responses. With a little bit of code, your Internet-connected lawn sprinker controller can load its watering schedule from a mesh object in your Live Mesh!
We provide .NET client libraries to facilitate using the Live Operating Environment (LOE) services in your app, but .NET is not required to talk to the LOE or to specific services in the Live Services cloud – you can also talk to Live Services (and the LOE) with RESTful HTTP requests built on industry standards such as Atom, RSS, JSON, and XML using whatever programming tools you want, from whatever device or platform you want.
Mesh Enabled vs Mesh Aware
A mesh-enabled web app is a DHTML or Silverlight web application that can not only talk to mesh services and access the user’s mesh data, but the app itself is a mesh object deployed and sync’d through the cloud to whatever Internet browser enabled device the user has in front of them.
A mesh-aware application is any other kind of app, running on the client device or on the server, which talks to Live Services and can make use of user data stored in their mesh. These do not get the benefit of automatic deployment or updates orchestrated by the LOE, but they are also not restricted to the security sandbox of a mesh-enabled web app.
Online and Offline Modes
The user’s mesh data can be accessed by applications when the device is online. If the Live Mesh client is installed on a device, apps can access user mesh data even when the device has no network connection. Data changes written to the local LOE while offline will be sync’d to the cloud LOE the next time a network connection is available.
The Live Framework automatically synchronizes data changes between the local client and the cloud, in both directions. The user can select which Mesh Objects are sync’d to which devices in their mesh. You’d want to sync photos from your cameraphone / mobile device up to a mesh folder in the cloud, but you would probably not want to sync all of your photos in the cloud down to your phone.
Mesh-enabled and mesh-aware applications use the same APIs / HTTP request patterns to access user mesh data in the local LOE as to access user data in the cloud LOE. What changes is the domain name used in the HTTP request (localhost:port versus cloud domain), and that’s needed only when making the initial connection to the LOE. After that, all LOE requests are relative to the base URL of the selected LOE. And if you’re using the .NET client libraries, nearly all of that local/cloud selection will be taken care of automatically behind the scenes.
User Authentication, Authorization, and Delegation
You can use the LiveID SDK to enable users to log into their mesh account from within your mesh-aware desktop or device applications. You can also use LiveID in your own Windows Azure cloud services: read Windows Azure Integration with Windows Live ID, Active Directory and OpenID.
You don’t have to use LiveID. If your app is a server-side web app or other service that the end user cannot log into directly, you can use Live Service’s delegated authorization to obtain an authorization token that you can use to access data in the user’s mesh independent of the user’s login state. The user has to opt in to giving you that token, and can revoke your access (invalidate the token) if you don’t play nice. The authorization token is cryptographically bound to your domain and the user’s id.
Mesh-enabled web apps don’t need to do anything with authentication because the user will have already logged in prior to executing the mesh-enabled web app, and the web app lives “inside” that authenticated sandbox context.
The user can choose to share a Mesh Object with other users. If your app writes to a particular Mesh Object and the user shares it with others, your app data can be distributed to the social graph without any work on your part. Your app can also see who has access to or is sharing the Mesh Object.
A Few Scenarios
- A desktop .NET application (written in any .NET language) reading and writing app data to the user’s mesh.
- The same app (same binary executable module) writing data to the user’s mesh while the machine is offline. (local LOE)
- A desktop Win32 application reading and writing from the user’s contacts. (LiveID SDK + raw HTTP / AtomPub)
- A web server app that writes data to a mesh object in the user’s mesh in response to a button click or form submit. (online)
- A headless cloud based web service that updates data in the user’s mesh every 3 hours. (delegated auth)
- A Silverlight mesh-enabled web application running on the local desktop (via Live Mesh client) while offline. (Offline Silverlight!)
- A Silverlight mesh-enabled web application that displays interactive features on current events, updated continually (daily) with new content and code logic (online/offline, data sync and app sync)
- Store your application’s personalization settings in the user’s mesh. The user’s preferences follow them to any machine they run that app on, regardless of whether your app is a mesh-enabled web app or a traditional installed desktop app. (Think: student computer lab. Many machines all configured the same used by many students all demanding to be different)
- Same as previous scenario, but now across different kinds of devices. User’s preferences and settings sync across PC, Mac, cellphone, etc.
- Briefcase application: Grab a dataset of client leads into your mesh-enabled sales lead app while at the office. Review client dossiers while offline in transit. Update sales contacts and enter purchase orders at client site, while offline. Sync changes and purchase orders to office (to a cloud mesh object shared with and watched by a mesh app at the office) at an Internet cafe in the airport on the way to the next client. Show next client how to enter orders themselves using your purchase order mesh-enabled web app (the same one you have running offline on your PDA-phone) running in their browser.
These are just a tiny sampling of the kinds of things you can do with the Live Framework. There are many more features I haven’t mentioned that add additional dimentions to the sample matrix: your mesh-aware and mesh-enabled apps running on the client device can programmatically construct resource scripts (expression trees) which can be executed on a server in the cloud (to move large data around on the server without making a round trip to the client across the network); there’s a server-side cross-domain proxy service that lets your mesh-enabled web app (executing in the context of a cloud domain name) “phone home” to your own web server or domain; and so forth.
If I had to name one thing that sets the Live Framework head and shoulders apart from other products that attempt to bridge the online/offline gap, it has to be Live Framework’s data synchronization. Other tools such as Google Gears can help you run your web app offline, but getting your offline data back into the cloud is left as an exercise for the reader. In Live Framework, synchronization is a fundamental assumption, a cornerstone of the core architecture.
When data automagically appears in all the places it’s supposed to go, you suddenly find that you have a lot less code to write, debug, and maintain. You can get back to focusing on business logic and spend a lot less time on infrastructure.
With apologies to ‘The Bard’