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.”
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.”
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.