Behind Live Mesh: Live Desktop architecture

As the unveiling of Live Mesh is a tech preview of the platform, similarly the Live Desktop release is only a glimpse into what will be available via the web portal. The promise is a rich cross-browser web experience that requires no installations, but will offer an enhanced look-and-feel if plugins are installed. I’d like to take a moment to describe the architecture of this Live Mesh platform experience and illustrate how the design will enable it to grow into a much richer experience. Let me warn you that this is intended to be a detailed developer-focused post. The key architectural features are the generic presentation framework; Live Mesh communication layer; Live Desktop windowing system; and C# to JavaScript compilation with Script#.

The generic presentation framework can be easily reused and extended to rapidly create performant data-driven applications. Its design resembles that of Windows Presentation Foundation in that there exist two clearly separated trees, one logical and one visual. In addition to being a natural separation for JavaScript and HTML, this has made code reuse and the addition of new features significantly faster and more seamless as logical controls can be customized with different styles for different UI components. The notable base classes in the logical tree are the UIElement and UIGroup.

The UIElement is the base class and has a one-to-one relationship with a DOM Element, handles input events, supports command routing, and participates in databinding. The UIElement performs memory management by removing its associated visual element from the DOM and detaching its event listeners when disposed. Command routing offers a convenient way of bubbling events through the logical tree to notify parent containers that an event has occurred. Databinding offers a very flexible way to present data as a UIElement may listen for specific property change events and update its associated visual element when these occur. In our framework, Binding objects are reusable and are composed of a source data property, a target UIElement, and a Converter which contains the logic for rendering data.

The UIGroup is a collection of UIElements and is the base class of all elements that participate in the rendering pass by the layout host. For expensive rendering events that involve more than small DOM manipulations, the UI Group will be added to the queue of items to be rendered and then its OnRender method will be called to perform the visual changes. It is worth mentioning the ItemsControl, which derives from UIGroup and represents a collection of data. The ItemsControl is instantiated with a shared visual template that is applied to render each item.

The visual styles are defined in resource dictionaries, which are reusable html string snippets sent down in JavaScript files. DOM elements are instantiated from these strings, keyed by id. This offers performance benefits as each snippet is sent over the wire exactly once and cached by the browser.

Let’s look at a short example of how this framework is used to render the Icon View of files within a folder explorer on the Live Desktop. The files are represented by a ListBox, which derives from ItemsControl and extends it by maintaining a selected item. The style for the visual template for each item is defined in the resource dictionary as:


<div id=””$spaceIconItem””>
<img id=””iconItemImg”” />
<div id=””folderViewNameCellLabel””></div>


The image represents an icon specific to mime type and the label represents the name of that file. When the visual template is executed to render an individual item, it sets up databinding for each of these DOM Elements:

“Src”, CommonBindings.MimeTypeToMediumIconOneTimeOneWay);
“Text”, CommonBindings.NameOneWay);


The image source databinding will be executed only once, and will set the src property of the img to be that of the appropriate icon url. The label text will be updated whenever the name of the file changes and will modify the InnerText of the div. The ListBox will be added to the rendering queue of the layout host whenever the collection of files changes, for example by navigating into a new folder, and will instantiate each of its DOM children by invoking the above visual template.

For completeness in discussing the presentation framework, it is important to note that each collection of data in memory is stored in an ObservableCollection, which maintains a list of items and fires unique change events when items are added, items are removed, or the entire collection changes. This enables an ItemsControl to intelligently decide whether to render an individual data item or the entire collection.

The Live Mesh communication layer updates the ObservableCollections by performing incremental data requests on corresponding data feeds on a recurring interval. This layer also performs the http operations that result from user actions. It maintains a queue of operations and associated callbacks. It understands the Live Mesh cloud API and provides a layer of abstraction between app-specific transactions and the semantics of the Live Mesh platform.

With all of the above infrastructure in place, it was straightforward to build a windowing system into the Live Desktop. The list of windows is maintained as an ObservableCollection. There are three different templates applied to render each window depending on whether it is in the taskbar, on the desktop, or in the window toggle control (shift+tab to see this view). Activating a window simply means setting the ActiveWindow property true, as the css class of the DOM Element is bound to that property. Opening or closing a window will fire a granular change event from the ObservableCollection that the ItemsControl listens for and will respond to by adding or removing the individual item from view.

The architectural complexity and heavy usage of inheritance described above were greatly facilitated by Script#, a C# to JavaScript compiler developed by Nikhil Kothari. The strong IDE support from Visual Studio and compile-time syntax checking that this offers have been crucial as the Live Desktop codebase has grown.

What all this means is that the foundation has been laid to add many more exciting features to your Live Desktop. When you view it today, you should see a visually appealing view of a desktop that works well cross-browser, performs responsively once loaded (and will soon load faster), and enables you to traverse your cloud. You might also think to yourself “I wish I could upload more than one file at once” or “I wish this SilverLight media view wasn’t one-size fits all and only worked on a subset of my data”. The good news is that these features and many more are planned and that the Live Desktop architecture will facilitate adding these new components rapidly. While we have a clear set of features that we think will make this offering more compelling, we are eager to hear ideas from you.

– Alex Himel, developer for Live Desktop

Technorati Tags:

Comments (12)

  1. joewood says:

    Thanks for the post.

    It’s not clear from this if  you intentd to open the desktop to 3rd parties to contribute functionality.  Is this something that you are looking to do?

    Also, a portion of the desktop seems to be running Silverlight.  Is it used just for media rendering or for any of the desktop views?

    Going forward would you consider less of a lowest common denominator, a WPF ‘live desktop’ or Silverlight only?  Maybe even a virtual folder in Windows explorer?

  2. Maxime H. says:

    It’s possible to edit file( Word or Powerpoint) online with the live Desktop?

  3. Mike Galos says:

    As I’ve been saying (and is getting more apparent with each post here)…

    File Sync is to Live Mesh


    Microsoft Write was to Windows 1.03

    This is going to be an amazing platform!

  4. Stumped says:

    Yet another UI framework? How many is that now? Let’s see if I can recall all the APIs that being actively promoted: Win32 (aka the tried and true), WinForms (when you must go managed and still want some perf), WCF (when you want sexy and slow), DUI (what happened here?), and now GPF? What gives?

  5. MSDNArchive says:

    These are great questions joewood. I’ll answer each one individually.

    We have developed Live Mesh to be an open platform. You can expect to hear more about our developer platform late this summer.

    Currently, the Silverlight experience is limited to media. This feature was designed and implemented very close to the release as a way to validate Silverlight integration with our cloud and to offer a way to interact with media elements inline. You can expect to see significant iteration this summer around both this experience, as well as other uses of Silverlight within the desktop.

    The current goal of the Live Desktop is to meet a lowest common denominator for basic functionality, and to offer an enhanced experience for users who do choose to download add-ons. A WPF version of the Live Desktop is unlikely because we want the Live Desktop to be available cross-platform and cross-browser. A Silverlight-only Live Desktop is certainly possible at some point in the future, but we are focusing on the HMTL/JavaScript version for now.

  6. MSDNArchive says:

    Great suggestion Maxime. That is definitely on our long-term wish list.

  7. MSDNArchive says:

    Let me clarify the proposed benefits of the Live Desktop architecture a little bit. The architecture is very well suited for the purposes of a rich AJAX application and as an extensibility model for the Live Desktop. Beyond that, at this time, it is not being advocated as a one-size-fits-all framework for web development. It introduces many interesting paradigms that are not often used in AJAX programming, most notably data binding, reusable controls, resource dictionaries, and the heavy usage of inheritance. I hope developers find this interesting, and am curious to gauge interest in offering the framework independent of components specific to the Live Desktop.

  8. joewood says:

    Thanks for the information.

    Personally I’m not that interested in an HTML based desktop.  I can’t imagine using it over and above a native desktop – what scenario is it being aimed at?  When a user only has access to a locked down shared PC ?  

    Rather than spending time working on an HTML version of Word (i.e. Google Docs) – I would prefer to see a Mesh enabled Office.  Where the ATOM feed could be used to synchronize part of the file being edited to enable online collaboration.

    And maybe a Silverlight version of Word/Excel, with cut down features that match something like Works and can be deployed in a sandbox.

    Just my few cents.

  9. Wei Zhu says:

    Good article. Alex.

    It would be cool to see more detail documentation. For example, a couple of examples with code and as well illustration of the corresponding visual tree and logical tree.

  10. Partha says:

    How does LIve mesh bypass corporate firewalls? Please reply to

  11. Live Mesh says:

    Hey there! I&#8217;m Viraj Mody , a developer on the Live Mesh services team. I bet some of you are curious