I did a bit of proof of concept work using MEF about a year ago.  MEF is all about composition of providers and consumers.  MEF’s main job is to connect the providers to the consumers so that when the consumer code executes, the providers they require are “just there.”

As trivial as that sounds, it significantly changes how you think about programming.  It forces you to think in terms of composition instead of in terms of plumbing and bushwhacking.  As a result, you can focus more energy on solving your actual problem instead of spending the majority of your time building the plumbing and scaffolding so that you can get to the point where you can begin to solve your problem.

For example, if you’re writing some code and you require “X” to get your work done, you write your MEF code module to declare your need for “X”.  When your module is loaded by MEF, MEF will take care of the dirty details of finding a provider to fill your need for “X”.  The provider may be the one you had in mind when you wrote the code, or it may be completely different, but as long as it implements “X” faithfully, you don’t really care.  The application defines the list of providers to choose from – whether a fixed list determined at build time or a list gathered at runtime – the point is, you and your code don’t need to deal with the how, just declare the what and keep going.

MEF alters your coding thought process from

“I need to figure out how to load and connect to something to get the X that I need”

to

“I need X.  I can rely on X being here when my code executes.  If for whatever reason X isn’t available, my code won’t be loaded so I don’t have to mess with all that.”

This change in thought process is similar to the shift that can and should occur when you go from writing traditional fire-brigade error handling code to writing code in an exception handling environment. For most of the code in your app (the middle layers), you can operate under the mantra of “If execution gets this far, then everything prior to this must have succeeded.  If anything back there failed, it would have thrown an exception so I wouldn’t be here now.”

I’ll see if I can get clearance to blog about my little MEF experiment from awhile ago.

Share/Bookmark

Silverlight was the primary deployment vehicle for live online video coverage of the Olympics last summer, and more recently live video coverage of the Obama inaugeration last month.  Moonlight enables Linux users to view video and applications built for Silverlight on their Linux boxes.

Scott Guthrie has more details here.

Share/Bookmark

Scott also sketches out some details on the Silverlight 3 release planned for sometime next year.  H.264 support, hardware GPU acceleration, and at long last proper design-time support for Silverlight in Visual Studio.

Share/Bookmark

First, let’s look at what kinds of applications can access user data stored in the user’s mesh (after user consent, of course):

1. Silverlight mesh-enabled web apps
2. DHTML + JavaScript mesh-enabled web apps
3. Server-side web applications (Windows Azure, ASP.NET, Apache, PHP, etc)
4. Cloud-based web services (Windows Azure, Amazon EC2, Google Apps, etc)
5. Desktop .NET apps
6. Win32 apps
7. Win64 apps
8. Linux apps
9. Mac apps
10. Mobile device apps
11. 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.

Data Sync

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.

Mode Transparency

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.

Sharing

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 DHTML+JavaScript mesh-enabled web app running in the browser reading and writing data to the user’s mesh. (online)
• A Silverlight mesh-enabled web application running on the local desktop (via Live Mesh client) while offline.  (Offline Silverlight!)
• A DHTML+JavaScript mesh-enaabled web application running in any JavaScript-enabled browser on a smartphone. (online)
• 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’

Share/Bookmark

Now that this is all out in the open, I can finally tell you what I do.  I (re)joined Microsoft back in June to work on what is now called Live Framework Tools for Windows Visual Studio.  (Quite a mouthful.) 

You can use the Live Framework to talk to Live Services, and to build apps that live in the Live Mesh environment.  A Mesh-enabled web application can execute via Live Desktop in the browser, or the user can opt to run the mesh app on their desktop using the Live Mesh client software. 

The same runtime that synchronizes data files in Live Mesh shared folders, the LOE (Live Operating Environment) will keep the local cache of Mesh-enabled web applications in sync with the cloud.  If a local instance of the app modifies one of its internal Mesh Objects, that change will be sync’d back to the cloud and seen by all other instances of that application in the user’s mesh. Similarly, changes made to the app or its data in the cloud will be sync’d to any local instances on a given device the next time the device is connected to the network.

The code you write in the mesh application doesn’t need to care much about whether it’s running in the local LOE or the cloud LOE, since both LOE’s implement the same APIs and services.

The Live Framework SDK’s client libraries currently include JavaScript, Silverlight, and desktop .NET libraries so you can write mesh apps in the context of an HTML web page or create a stand-alone “mesh aware” desktop application.  You can access Live Services using any tool/language/device that can talk HTTP, but the Live Framework client libraries make it a lot simpler by taking care of the low level gorey HTTP details.  I’m sure we’ll see additional libraries pop up in the field to automate the low level HTTP stuff for other dev tools such as Ruby, Perl, Python, et al.  Delphi, btw, is covered by the Live Framework SDK’s existing desktop .NET library.

And of course, you don’t have to start from scratch - you can use Live Services in your existing web or desktop applications with a little bit of code and a recompile. Your existing Silverlight projects are probably also mesh deployable with little or no changes.

My team (Cloud Computing Tools) implements Visual Studio extensions to handle creating, editing, deploying, and debugging Mesh-enabled web applications running in the Live Mesh cloud.  If you’re a .NET nut, we have a Silverlight Mesh-enabled web app project for you.  If you’re an HTML JavaScript jockey, we’ve got an HTML Mesh-enabled web app project type as well.  Both can be edited, deployed, and debugged within VS.  If you’re working on a traditional desktop .NET application, you can just reference the Live Framework assemblies in your existing project – no VS extensions are needed.

Actually, only part of CCT is working on mesh tools - the majority of the team is focused on building Windows Azure Tools for Microsoft Visual Studio for writing services that execute in the Windows Azure cloud environment. 

For Azure dev info, check out Gus Perez’s recently revived blog.  Gus is on the Azure side of the CCT house and would blog more often if I would stop sending him stupid VS n00b questions in IM.  Jim Nakashima of Azure tools has also been blogging on Azure, though I think he may have an easier time of it than Gus because I don’t have Jim’s home phone number.  (Yet)

Chuck Jazdzewski is also here in CCT and is the architect of my return to Microsoft.  If you know Delphi, you know Chuck.  Though Chuck is officially working on “deep research,” he chipped in quite a bit to help get mesh tools off the ground.  (Thanks Chuck!)

I’ll be trolling the Live Framework forum to answer getting started questions, and hopefully posting a few Live Mesh app demos here later this week.

Share/Bookmark