Archis's Blog

Finally, the long-awaited unique take on what Live Mesh is all about as seen from my eyes. Live Mesh was announced publicly about a week-and-a-half ago with an entry by Amit Mital on the Live Developer’s Blog at 9:00pm PST. I hope everyone has read all there is to know about Mesh, and for any further information point your browsers to http://www.mesh.com/blog. Do ask questions and express comments on the Live Mesh Blog – there’s no such thing as too many questions. After all, when a team has worked for months to ship something so awesome, they are only eager to interact with the community.

The Technology Preview available on Mesh.com has a limit of 10,000 users which I think has been filled up by now. It has been quite fun to see how fast the word spread and filled up the positions. It is important to note that Mesh is still in a very early preview and as we approach the Professional Developers’ Conference (PDC) in October more details will emerge.

I will try not to re-hash all the stuff that’s been said and re-said about what Mesh is (or isn’t), and offer my own take on what this is all about from a very high-level perspective. One of the interesting things about Mesh in the first few days after announcement, was how it related to everyone in a different way – “It’s software, It’s a service, no….. It’s Mesh!” As Obi-Wan Kenobi rightly said (is there anything the Jedi philosophy doesn’t apply to?), “Many of the truths we cling to, depend greatly on our own point of view.”

Mesh is a piece of software, Mesh is a service (or a bunch of services) running on the cloud, and Mesh is an experience (Sharing of files and folders), and in my personal opinion, Mesh is, above all, a set of design principles or architectural decisions (enter the developer’s take on Mesh). When I joined the team an year ago, what really excited me to come work here was the very clear communication from higher-ups on what we were building.

People have been writing software for many, many years. Services are perhaps new, catching on only after the Internet became widespread, and yet they have been used more than ten years now. The concept of connected software isn’t all that new – Yahoo Messenger being a legend in my circle of friends from high-school days. What differentiates Mesh is the way everyone thinks about it – which is exemplified in Ori Amiga’s developer video.

Let me take a moment to clear up the definition of “Cloud“. The phrase Software + Services is widely misinterpreted as some kind of lame software using sockets to talk to some server. “Big deal!”, right? Well not quite. By cloud we don’t just mean one service running on a Microsoft server. Cloud is “anything that’s not you – but can interact with you”. When we say “Your files come down from the cloud”, we say so because there really is no other way we can phrase it. Sometimes they come from a peer desktop MOE, or from our own web services, or from a Feed Sync provider out there who wants to Mesh with you! When you connect to the Mesh, you literally connect to “the cloud” and not a specific end-point. The Mesh only always adds value, never takes away. It doesn’t “absorb”, it “sync”s – it’s bidirectional. You add value to the Mesh and the Mesh adds value to you – whether you’re a software, a service, or anything else we haven’t imagined yet. As long as you can do a “GET http://[some_url]“, you can talk to the Mesh, and by extension, anyone else that talks to the Mesh – tell me that didn’t just get you clamouring to be on our Developer SDK waiting list.

Look at the Live Folders experience – it wouldn’t be too difficult to write some TCP/HTTP code in Windows Explorer to make it to do all the stuff Mesh allows it to do. Similarly, shouldn’t be too difficult to write an app to share comments on files either. Moving these comments from one machine to another? Sure, how tough can that be? Now how about a list of friends? Pretty easy (I did all that in school). Then comes the interesting part – I have code to read my list of friends, can I use it to read my list of comments as well? Oh sure, all in a day’s work. Then how about allowing it to read any list of unknown data that I want to share? Perhaps slightly annoying, but doable. And finally, how’s about doing it in a format that the entire world understands and uses so often that it is crisply and clearly defined. Then comes a minor twist – even if I’m not connected to the Internet, I want my app to be able to send these lists across – and I want someone else to make sure it reaches the destination safely and securely. Why should every app write the caching/transport logic over and over again?

And that is what Mesh is at heart – the few guiding principles around which software and services were built. Rather than focus on “What will this service do to keep it extensible?”, the Mesh team focused on “How can we represent anything and everything so that anyone can read it anywhere in the world?”. The subtle difference here is the pivot point – for some, the pivot is the service, it is the hard absolute that cannot change. Everything else must be written around it to accommodate it somehow. Mesh has universally-readable data representation as it’s pivot – services and software were written around it. To put it another way, the software+services implementations are a natural consequence of the design, rather than interoperability being the consequence of the implementations. Enough abstract philosophy, let’s look at how these principles rendered themselves in practice:

1. Everything works over HTTPS. Since almost any conceivable device that can do anything data-related can talk HTTP, this means all devices can talk to each other – across NAT’s, Firewalls, etc. The S at the end of HTTP guarantees encryption – and I mean good-enough-for-my-bank-to-use kinda encryption. Hundreds of millions of dollars in online transactions are protected by HTTPS every single day.
2. Anything and everything is a feed. List of users? Feed! List of Devices? Feed! List of friends? Feed! List of all these feeds? Feed! Now at the core, all you need is a Feed reader, and you can read anything, anywhere. You might have seen Amit Mital or Ori Amiga demoing the cool Data Model Browser – it’s a feed reader on steroids and it can read anything in Mesh.
3. What kind of formats are these feeds in? You name it! RSS? Yup! Atom? Yup. Something easy to use in my cool AJAX app? JSON! No more glue logic on the server to pull data from a SQL database, convert to JSON, send to AJAX client, and render it (I’ve developed many a website that did this in the past.) Now just point your RSS reader at the comments feed on the file you’re interested in, and voila – what was a software, became a service!
4. Always use, what I like to call, Wikipedia Formats – due to Amit Mital’s inspiring description, “Formats that are not only standardized, but also can be described in a page or two and a large number of developers know how to use.” The Mesh team could have gone with some cryptic ISO/xxxx and then people would have spent a while reading about it, and then we’d have general chaos on how to resolve the boundary cases which the spec failed to anticipate. Instead, Atom’s been used and reused and talked about and discussed and spec’d the hell out of so much that you have ready answers on Wikipedia, hundreds of articles, tutorials, blogs, friends, etc.
5. RESTful model – REST stands for “Representational State Transfer“. Think of browsing the Mesh using the data model browser as moving through a Turing Machine. Each state is represented in the URL you are currently at. What’s cool in this model is that you can now get to a specific location in the Mesh Data Model, and just copy that URL to a friend to allow them to view it too (so long as they have permissions, of course). This way “discovery” of data becomes easier. Imagine telling them to execute a few RPC commands to get to the same data.
6. And thanks to the platform background of Microsoft – this one came quite naturally to all involved – never ask developers to compromise on their native environment. This is the real killer design principle that made .Net a success and will hopefully do so for the Mesh. There have been legendary historic debates around Editors (vi vs. emacs reached galactic levels in the 80’s), IDEs, Programming Languages, styles, paradigms, and API libraries. Each developer LOVES his specific environment – try and separate it from him and you’d sooner choose to steal candy from a baby. Yes, we developers, are opinionated and stubborn – and that’s what makes us so effective. If I run on a Mac, I want the full immersive Mac experience – using Mac metaphors. When I use a phone I want a full phone-like experience. Wouldn’t be much of a “Mesh” if it all looked and behaved the same everywhere, would it?

Now for stuff I’ve been dying to tell people – my personal favourite scenarios which Live Mesh simplifies (I’m sure everyone can think of hundreds of cool things to do once you’ve watched Ori’s video). Just look at how simple it is to develop rudimentary apps:

1. My personal favourite: Mesh Mail. Mesh is much like e-mail already – MOE’s acting as SMTP agents forwarding data/feeds to other MOE’s. A rudimentary messaging platform would involve creating a Mesh Object between each contact of mine (yes it would lead to a Cartesian product of objects – but look at the simplicity). To “send a message” all I do is post a data entry to it’s “Message Feed” on my local MOE. Through Mesh Magic, the peer app on his machine gets the entry and he receives a message. Just like that! He isn’t on any physical machine? The same thing is available on the Live Desktop.
2. Instant Messaging: The mail scenario extends to IM even more beautifully. Create a feed for a two-way chat. All you do is post data entries to a feed, and in your chat window, display updated feeds whenever you receive notifications. That’s it! IM across the web, across rich WPF experiences, low-end phone experiences, you name it!
3. How about boasting about your AOE scores between friends? Just create a feed, post your scores!

As you can see, each “App” is a separate app and is also the same app. AOE scores are still data entries in a feed. But they are also a distinct app – displaying them as email is doing injustice to all the cool 3D desktop capabilities you paid for. This is where the “Software” from Software+Services comes into play. Today, we leverage the same old software for multiple applications due to the sheer start up overhead of writing connected software. We use e-mail for forwarding favourites, discussing movies, debating philosophy, sharing files, and boasting about our AOE scores. With Mesh its just the opposite – you may have the same feed storing all this data, but the experiences are customized based on the content – Movies might get you a complex and powerful mashup for commenting, rating, sharing, etc. AOE scores will give you rankings, statistics, etc. Sharing files – you’ve already seen.

That’s concludes my take on why the Mesh is so important and what turns me on about it. With all that Mesh can do, it still can’t use butterflies to focus cosmic rays to write code.

Technorati tags: LiveMesh