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.

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

Major features in this release include revision history, comparison, and rollback of edits made to articles, a “Press this” link to automate blogging about other web pages, theme previews to see how a theme would look on your content before committing to it, support for using Google Gears to cache WP administration scripts locally, and many smaller improvements such as built-in support for placing captions on photos included in blog posts, better WYSIWYG image control in the editor, SSL support for WP administration, and quite a bit more.

As mentioned earlier, WP’s initial use of Google Gears only accelerates loading of WP administration pages (manage the blog, edit posts, etc) by caching the WP scripts on the local machine.  While this may seem like a minor improvement (except to those with slow Internet connections), this is an important first step towards being able to create and edit blog posts in WP while offline.

Of these new features, the image caption and improved image control in the editor are probably the items that I would use and appreciate the most. I don’t see a burning need to roll back to previous edits on an article or preview new themes (I have my theme, now leave it alone).  I might take the Gears support for a spin, but I doubt it will make any noticable improvement to my WP administration experience on my multimegabit Internet connection.

As much as I’d love to play with these new features (and WP 2.5 as well), the biggest obstacle for me (and many others) is the update install process.  The WP update instructions do a great job of whittling it down to a “Three Step Upgrade“, but one of those three steps (33% of the process) is potentially delicate and/or scary.  If you don’t dedicate your full attention to what you’re doing, you risk wiping out your blog content or your blog custom settings completely.  This is a not a one-button install.

WP update step #1 starts with the instruction “Copy the new WP files to your server, overwriting old files in the root” but then follows with a list of very important exceptions of things not to overwrite.  That doesn’t instill confidence.  You have to read all the instructions and apply the subsequent exceptions and filters in reverse order.

I’ve updated WP on my server before.  It went smoothly, and the actual update step did only take about 5 minutes, but it required more than an hour of my attention in nervous preparation and validation.

I would love to switch over to using Subversion to update my WP installation directly from the WP servers.  This would be the closest thing to a one-button install of WP.  I have much greater confidence that Subversion would preserve my local changes when applying updates, or at least notify me when there are conflicts I need to sort out, than I have in doing the same work myself by hand.  However, installing Subversion on the server requires root access, and my web host does not have Subversion in their suite of installed software.

So updating to the latest WordPress release falls back to the “some rainy day” list of chores.  (And we’re unlikely to see a rainy day here in Santa Cruz until at least November!)

via Weblog Tools Collection

Share/Bookmark

This isn’t really the best use of Gears, since the browser will cache content as it’ is accessed, but it’s a reasonable first step.  Clearly the longer term goal (in the upcoming WordPress 2.6 release?) is to support blog post editing and administration while offline.  I imagine this prequel to full offline mode benefits WordPress.com (by reducing server traffic) more than end users. 

Some of the comments on the WP.com blog post indicate little or no noticable performance boost for the end user.  If you have a fast Internet connection, that’s probably going to be the case. It sounds like what WP.com is using Gears for (for now) is to prefetch the admin scripts, pages, and images to the local cache. WP.com bloggers who would see the greatest performance improvement would be those on a slow or crowded Internet connection.

I was surprised to see on other blog posts on this news comments expressing fear of “sending all their data to Google” and the like.  That’s not what Gears does. Gears is a browser plugin to enable a web site (wp.com) to store data on the client.  None of your WP.com data should ever be sent to Google, period. I don’t think WP.com even has to have a reference to Google to get the Gears JavaScript – the Gears JS code can be completely hosted on the WP.com server.

Some will raise the concern “What if Google embeds a trojan horse in the Gears code?”  Well, it’s open sourced so somebody will see it if there is such a thing, so this shouldn’t be a real concern.

There is no issue of Google getting access to WP.com blog data as a result of using Gears.

Share/Bookmark