Nov 182008

Dare Obasanjo has written up his characteristically frank first impressions of Live Framework and how it compares to Google’s GData API.  It’s a good read:  Live Framework (LiveFx): Is It Microsoft’s GData or Something More? 

 Dare closes the article with this:

On the flip side, the client-side Live Operating Environment is a technology whose benefits elude me. I admit it is kind of cool but I can’t see its utility.

The answer, in a word, is “offline.” 

The local Live Operating Environment (local LOE) is what makes running mesh-enabled web applications on the desktop, outside the browser, possible.  The local LOE creates and manages a sandboxed execution environment for the mesh app, just like a browser would for an HTML+JavaScript or Silverlight application but without the browser UI frame looming overhead. 

It seems like a trivial thing, whether or not the browser frame surrounds your app UI. Does it matter? The answer is yes – having your app surrounded by browser UI constantly and forcibly reminds the user that this isn’t a real app, it’s just a web page with lipstick.

This is doubly true if you throw offline execution into the mix.  We’ve done a great job drilling into non-technical heads that viewing the web is an online activity (Yes, browsers have offline cached content modes now, but have you ever seen any non-geek use them?).  Now say we’re offline.  “I can’t get to the web, but I can get to that app in the browser?  (wimper) I don’t understand!” or “I click on this shortcut and it brings up my app in the browser. Hey! Is the network connected?  How did that happen?”

There is no such confusion when the user perceives a desktop application that uses the network. The best way to dissociate the app from the browser is to not show the app inside the browser. Thus we arrive at one of the holy grails of web apps: to run on the desktop and look just like any other client app on that local machine.

But I digress.  Back to the LOE.

The local LOE coordinates the data sync between the cloud and the local machine to keep the local cache of Mesh Objects and their data feeds up to date with changes made in the cloud, and to push changes made locally up to the cloud.  This includes pulling down updates to the mesh apps themselves, since they are stored in Mesh Objects also. (Well, isn’t that conveeenient…)

The local LOE manages the user login and identity for mesh-enabled web apps running on the local desktop, just as the browser does for web apps running in the browser.

The local LOE implements the Live Framework APIs for data feed reading, editing, and synchronizing, so that a mesh-enabled web app can use the same APIs with the same semantics whether it’s running in the browser talking to data stored in the cloud or running on the local desktop talking to data stored (cached) on the local machine.  The only real difference between cloud and local is the domain name, and the mesh app doesn’t even have to care about that (the Live Framework client library will take care of it).

Having the local LOE doing all of these things on the local machine gives you the ultimate goal: running mesh-enabled web applications offline, while the network connection is disconnected completely or connected only intermittantly. The local LOE provides the execution environment, the data storage and data sync, the user identity credentials, and the RESTful APIs that the mesh app expects from a cloud – when there isn’t a cloud.

This is a very different approach from the path we chose when building Google Gears (I was a founding member of the Gears team at Google in 2005).  Google Gears is first and foremost a browser extension. We joked at the time that you can talk about getting the browser out of the app (creating “chromeless” web apps with no apparent browser UI), but not getting the app out of the browser. For Google, the browser is the platform, end of discussion. 

The Live Framework local LOE is exactly the opposite – it’s a client application that works like a browser.  It may even create an instance of the browser internally (I don’t know the internal details of the LOE) but it is fundamentally treated as “not the browser.”

Take the challenge of executing JavaScript while offline.  In Gears, we figured out some neat tricks to have our browser extension tap into the browser’s URL decoding stream, so that we could intercept requests for JavaScript URLs that we had cached or preloaded in local storage.  This even worked for desktop shortcuts that contained URLs to our web app.

In Live Framework, such interception tricks are unnecessary because you’re either running the app on the local desktop (in the local LOE sandbox) or you’re running the app in the browser (in the cloud LOE). Either way, the LOE knows what to do.

I’m making no argument that either solution is better or worse than the other, just that their architectural assumptions are fundamentally different.

Regardless of whether you’re in the Google camp or in the Microsoft camp, I think it’s a fair statement to say that these differences of viewpoint accurately reflect each company’s core strength and focus:  Google wants the browser to grow to subsume the desktop;  Microsoft wants the desktop to grow to subsume the cloud.

kick it on

  17 Responses to “Client-Side Live Operating Environment: What’s It For?”

  1. […] UPDATE: Danny has written much more about why the LOE is great. […]

  2. Danny Thorpe responds in his Client-Side Live Operating Environment: What’s It For? post of 11/18/2008 that “The answer, in a word, is ‘offline.’”

  3. […] was the concluding paragraph in a post by Danny Thorpe of Microsoft (and formerly […]

  4. […] was the concluding paragraph in a post by Danny Thorpe of Microsoft (and formerly […]

  5. […] was the concluding paragraph in a post by Danny Thorpe of Microsoft (and formerly […]

  6. […] was the concluding paragraph in a post by Danny Thorpe of Microsoft (and formerly […]

  7. ~ Thus we arrive at one of the holy grails of web apps: to run on the desktop and look just like any other client app on that local machine ~


    A ton of thought here.

  8. Jerry,

    Thanks for the links. Zeepe looks pretty cool, and it’s been out there for awhile already.

    But does Zeepe do data sync of app and user data to the cloud?

  9. ~ does Zeepe do data sync of app and user data to the cloud? ~

    Not wanting to reinvent the wheel – whilst also not wishing to ignite a gears-vs-live war of words – we did reckon that google gears should work in Zeepe. But we do need to double-check that.

    We also need to check whether or not the MS platform is open and usable in Zeepe, or are we tied to the LOE client. We suspect tied (i.e. it’s the client that does the sync etc etc rather than a re-usable toolset).

    Sorry – hardly a definitive answer!

  10. ~ But we do need to double-check that ~

    Just a quick followup to say that Gears works in Zeepe as expected … and it turns out that at one point someone here also produced a version of Gears for Zeepe that was prompt-free in the presence of a publishing license.

    Thanks for the interesting question, which has opened up the “who really has a synching issue any more” discussion here once again

  11. Jerry-

    Live Framework uses industry standard ATOM FeedSync protocol to handle data synchronization. The Live Framework Client provides a sync and execution sandbox, but these could conceivably be implemented by a third party to talk to the Live Services cloud using the same open protocols used by the Live Framework Client.

    Live Services, Live Mesh, Live Framework, and Windows Azure in general are not hard-wired to the Windows client.

  12. Jerry

    Also: Google Gears does not provide data sync. ;> It provides local storage for browser apps and a means to isolate the browser app from the network so that running offline is possible, but Gears does not sync data across the wire for you. You have to implement that yourself.

    The Live Framework / Live Mesh environment implements data sync for you. All you have to do is put the data into the user’s mesh and it will be sync’d to all other sites the user has chosen to include on their device ring.

  13. Hi Danny

    ~ Also: Google Gears does not provide data sync … ~

    Thanks a lot. That definitely chimes with what Pete told me earlier today:

    ~ Syncing is actually a really difficult issue – Google stepped away from it saying “application specific” (which I happen to think is true). I don’t know what Live does on this, there’s probably a bunch of APIs which you feed schema information and it does the sync for you ~

    So cheers, we’ll probably try to get ourselves bang up to date (again!) and have a play.

  14. Jerry,

    Yes, sync is a difficult issue when talking about arbitrary data with unknown semantics. However, if you apply a few modest constraints on the data and have some metadata about what the data is, sync can be performed quite well automatically.

    This isn’t anything terribly new – Borland pioneered the “briefcase” model of taking a dataset offline into a local snapshot, modifying it, and then sync’ing it back to the server of authority in Borland’s Midas data engine, shipped with Borland Delphi and Borland C++ back in the mid 90’s.

    The fact that Google Gears backed away from the data sync is one of my biggest frustrations – I argued this point for months while designing the Gears local storage interfaces between the browser and the SQLite engine but never gained any support within Google. The folks at Google had incredible depth of experience writing code, but noone I came in contact with had any idea what was available or possible in the PC database world. I had experience with database things through my work with Delphi.

    This undoubtedly contributed to my leaving Google to seek an environment that was more amenable to not just getting things done, but getting the “right” things done, tackling the hard problems, not just picking the low fruit. Gears solves some tricky problems in the web development space, but its formation was more about assembling known pieces to address a specific issue than about breaking new ground in software development.

    Hmm. I feel a blog post coming on… ;>

  15. Jerry –

    Live Framework doesn’t require a lot of API work to get data to sync. Live Framework requires that you organize your data into feeds and entries per ATOM spec, and that provides a sufficient semantic envelope for ATOM FeedSync to manage merging data changes between feeds.


  16. Danny

    ~ tackling the hard problems, not just picking the low fruit. ~

    From a recent Wired article it sounds as though your current environment not entirely un-amenable to that.

    We took the bones of Zeepe in a demo to the ’96 PDC and then for a few years fleshed it out with our own ideas and needs. But since it went commercial, its functional growth has been – as you would expect – almost totally customer-driven.

    Maybe its time for us to take the initiative back for a while … we’re working with ATOM feeds anyway in iMunch, our ‘proof of concept’ Zeepe-based news aggregator / tabbed browser / blogwriting tool:
    so I guess that we may not be starting from an entirely blank sheet.

  17. […] what mesh is all about, and shows another example of why the local client is so important as a game-changing facilitator.  Your mesh-enabled web apps and mesh-aware desktop apps or cloud […]

Sorry, the comment form is closed at this time.