This is great news for me because I maxed out my Live Desktop long ago  - now at least I’m no longer prevented from Mesh’ing  up everything I want – I just won’t be able to access those additional files online from other computers that aren’t my own.

Additionally, the new version of Live Mesh lets you manage file conflicts on the Live Desktop and it adds new “News Events” for when you add or delete folders from Live Mesh. A few more bug fixes and performance improvements round out this release.

Now, I’m off to Mesh up (hmm, that sounds wrong…) every folder I have.

Before we even had an official announcement, LiveSide was reporting last night that folks were able to sign up for Windows Live Mesh if they were located in the U.S. This morning, they confirmed this to be the case. The official announcement was made in the Live Mesh Forum. It read:

Live Mesh is now openly available to anyone in the U.S.

The Live Mesh team is pleased to announce that anyone in the U.S. can now use Live Mesh just by signing in to www.mesh.com with a valid Windows Live ID. No sign up needed to participate!

International Customers

With Live Mesh open to anyone in the US, our international friends can join in the fun early as well - with one caveat: you must be willing to change your Windows operating system region and language setting to EN-US. Once you do this you will be able to immediately sign in to Live Mesh with a valid Windows Live ID. Please be aware that this may cause other applications that specifically require your native country region and language settings to encounter problems.

Feedback

Once you've begun using Live Mesh, we'd love to hear from you! We are working hard to create the best experience and appreciate any feedback you have. Please send us feedback using our online form. You can also submit (and view others') feedback and bugs here on the Microsoft Connect website.

Thank you,
The Live Mesh team

About Live Mesh

If you haven’t checked out Mesh yet, you should. This software+services data synchronization platform isn't built with proprietary code, but rather with open protocols like HTTP, RSS, REST, ATOM and JSON. Although Mesh's FeedSync is somewhat new, it is an XML protocol based on ATOM and RSS.

With Mesh running on your computers, you can simply right-click any folder and choose "Add to Mesh." By doing so, that folder and all the files it contains are synchronized with all of your other computers you've added to your personal Mesh. It also syncs those files to the Live Mesh Desktop, which is Mesh's "cloud" - an online web site you can access from any computer. At the moment, the online storage is limited to 5 GB, but that could change in the future. However, Mesh's recent update allows you to set folders to sync via peer-to-peer, bypassing Live Desktop. When folders are Mesh-enabled, a small panel appears to the right of the folder in explorer which catalogs any changes to the folder (file adds/moves/deletions) as well as notes and comments left by any of the folder's members.

Live Mesh also lets you access all your “meshified” computers remotely, so if you have software that is installed only on one PC, you can use Live Mesh to access that computer as interact with it as if you were sitting in front of it.

Although today’s release doesn’t include a Mac version, we know that it’s under development and should be available soon.

• Updates to Live Mesh 
• Improve Desktop Search performance by downloading Windows Search 4.0
• Lots of updates to Popfly Game Creator from Adam Nathan
• The IE team sends Mozilla a congratulations cake (via Ars Technica)
• Update your Silverlight.js file for Firefox 3 (via Tim Heuer)
• DeepEarth: Virtual Earth + Deep Zoom (via Jamie Thomson)
• Ariel Stallings from Microspotting designs cool I am the empire t-shirts
• Video clip of Richard Sprague demoing Response Point and discussing how they used research to build voice grammars
• Sourceforge Community Awards will include Codeplex projects
• Soma discusses the Secure Development Lifecycle and how Microsoft uses it internally
• Golf Course powered by Virtual Earth 3D (via Mark Brown)
• Video clip of Tiger Electronics AMP robot
• Brian's Pick of the Week: James Devlin: Building a Real-world Poker bot with C++ (via Avi Pilosof)
• Dan's Pick of the Week: Walt Mossberg reviews GoGo: In-flight Wifi which will be coming to Virgin and American
• After the end, Dan, Brian, and Laura Foy unwind at TechEd

In this audio version of a Channel 9 video, Ray Ozzie discusses his role as Microsoft's chief software architect, and the role of Live Mesh as one aspect of an emerging Internet-oriented platform.

Ray Ozzie is Microsoft's chief software architect.

Links mesh.com Video of this interview on Channel 9 Abolade Gbadegesin on the architecture of Live Mesh Demo of Live Mesh on Channel 10 Mike Zintel on Live Mesh as a platform Background on FeedSync

JU: Hello Ray! Thanks for joining us.

RO: It is great to be here Jon.

JU: So, it's been about 3 years since you joined Microsoft, initially as CTO. People tend to wonder what it's like coming from a company of 300 to a company on the scale of Microsoft.

RO: I've had the luxury of career working for small companies: Software Arts in the early days, and a couple of startups in Iris and Groove. But Lotus ended up being acquired by IBM, so I was at one big company before coming to Microsoft. It's tremendous in terms of the potential impact that someone can have. I think everyone at Microsoft tends to be here because you want to have a tremendous impact, and certainly that was a tremendous draw.

What I really do enjoy about the role as CSA, is being at the juncture of business strategy, product and market strategy, and technical strategy. I have the opportunity to work with not only the executive team on larger strategic issues, but also with the product teams at fairly detailed technical architectural levels. As an engineer, it is really fascinating, and I've met a lot of great people.

JU: People also wonder what it's like to step into a role formerly occupied by Bill Gates. What kind of continuity will there be, and how might you want to reshape the role?

RO: Bill is a very unique individual. There will never be another Bill. He has got a tremendous palette of talents, both technical as he applied at Microsoft, and non-technical in the role he's moving into. In shaping the role after July, when he won't be here full time anymore, he really split the role into two pieces. Craig Mundie takes over long-term issues, research and things like that. And I have taken over most of the technical and product strategy related to products that'll ship within a couple years.

My background is different than Bill's was. I've been a lot more hands-on in the product design for a number of years. I'm dealing with broader issues than I've dealt with in the past, but my background in product development gives me a lot of grounding in terms of working with a development team. And I think Craig and I make a good pairing in terms of filling his shoes.

JU: How do you balance the need to span a vast spectrum of activities and the need to go deep on things?

RO: Time management -- attention management -- is really the biggest challenge. The pace is fairly brutal. At the beginning of the year, I'll kind of plan out how much of my time in hours I want to spend in different categories of things. There's some allocation for the rhythm of the business and high level strategic things. There are allocations in terms of time I want to spend with product groups.

And then there's a fraction I didn't initially realize I had to be as intentional about, but sometimes you have to create white space because, like a task scheduler that has too many ready tasks, you can thrash if you spend all day dealing in a reactive mode to the incoming issues, the incoming communications. Sometimes you have to create some white space in order to think and understand what is going on in the environment. I can do that by going away, by traveling to our international offices. Bill had something called Think Week that we are continuing in a slightly modified form going forward. And there are other ways.

JU: Is one of those ways maybe to sometimes focus deeply on particular interests of yours? If so, what would some of those be?

RO: Well, the problem is most of my interests are technically related and so in theory I would just go write some code. I don't do that anymore, though, and honestly the best way that I've found to clear my mind really is either to go to a conference that's a little off the beaten path, or just travel somewhere, maybe with my wife, that is not technology related, just to clear it out and re-prioritize. It is probably something that everyone has to do. In the old days when I did code, I used to have a 4-hour rule that said: "Do not write code unless you can at least have 4 hours of contiguous time where you will not be interrupted." Otherwise you end up introducing more bugs than the code you are writing. In a way, this is kind of the life management equivalent.

JU: So, in the talk that you gave at MIX, you introduced the interesting phrase "utility computing". I got to thinking that although "web 2.0" is the meme of the current era, people may have forgotten that for quite a while, Tim O'Reilly was actually trying to establish "Internet operating system" as a meme. That didn't really stick, and now it's come around again as "web 2.0", but "Internet operating system" is a pretty evocative phrase, as is "utility computing." We have talked about some things that are coming. We're going to talk more about a part of that initiative here, the Live Mesh announcement, but I wonder if you could reflect a little bit on what an Internet operating system could be.

RO: Maybe I should just step back and talk about the environment a little. I mean, when I got into this business back in the 70s, utility computing was really hot, it was called the mainframe. We had these raised floors, freon cooling. It really was a utility. We used virtualization. There was "time sharing". They were boring terms, but we were used to treating computing as a utility, and the PC revolution was all about empowerment and kind of getting back some of that personal feel, getting control of building solutions for things that might be really meaningful for you.

So the pendulum swung to the personal, and then with the web, when the web first emerged, it's odd, the nature of how technology is shaped is based on the constraints of the environment, whether it is computing constraints, communication constraints, and so on. The early web grew up in an era of dial-up, of 56K dial-up, so a lot of the way the protocols are structured, where computing was located, were based on that balance of computation and storage on the back-end, a really thin straw, a smart terminal that we call a browser on the front end, and that's how it was born.

Nowadays, we've got increasing ubiquity of broadband. We've got this big fat pipe so we can send more data. You still can't be chatty, but we can send more data back and forth, and it gives us, as architects, the ability to revisit what should be the right balance between, for any given solution, of what's on the back end and what's on the front end. We have amazing computation abilities on both sides. We have amazing storage abilities on both sides. So now, in this unconstrained environment, really the question is: what is the right way to build a solution? Application models have had begun to evolve that start to take advantage of some of these things on both sides, and I think really when we talk about utility computing now, what we are saying is, if you are building a solution now, what is the right way that back-end utility should expose its resources? What business models? What application design patterns are appropriate for the cloud? Map-reduce-like patterns, pure horizontally scalable patterns, are much better for that back-end.

What should the front-end programming model be like? We started with the PC in a model of one computer for some subset of users. Bill and Steves dream was to have a computer on every desk and in every home, and we have gotten into that point, but now we have gone beyond that point. Every individual has a phone and a PC. Many people have multiple PCs at home. They might have a PC at home, at work. We have got computer-like devices in our cars, sitting underneath our TVs with the set-top box. People have home security systems. There are lots of devices around, and I think now is the time to reflect, what is the right programming model for the client environment that we have got? What is the right programming model for the cloud? And at least from Microsoft, how can we built tools and services to help developers build great businesses, to build great solutions, using both those back-end and front-end resources?

JU: From that perspective, we see some interesting offerings emerging in what we can broadly call the Internet operating system space. Amazon surprised me quite a lot in the last couple of years in the things they have done. I don't think people were too surprised by the Google announcement more recently. I would invite you to reflect on the kind of company that Microsoft historically has been, and therefore, the kind of approach that Microsoft can take to this problem as it might compare to the kind of approach that these other companies can take.

RO: I have no products announcements to make. [laughs]

JU: I understand that. [laughs]

RO: I'll just reflect in our approach, and compare and contrast if you like. Microsoft's approach...I can tell you this because I was a developer for most of my career on the outside of Microsoft...I've been here for 3 years, but I had a relationship with Microsoft as an ISV since roughly the beginning the Microsoft. I met Bill and Steve in 1981 when I was first coming out to talk to them about some DOS issues. Microsoft, I believe, has always taken a perspective of ... its DNA is as a platform company. And in order to have a successful platform, you've got to have successful ISVs, people who are being selfish about their solution, what they are trying to deliver, but we have to -- semi-selflessly and semi-selfishly -- serve those people. We've got to build a good business, but we've got to do so by serving those people and letting developers build great businesses. So in any platform, any utility computing environment that we would consider, we would be taking a broader perspective.

We would look at a 20- or 30- year horizon and say: How is this all panning out? What is the broad range of developers out there? What does the new-age ISV look like? It's a web ISV. There are also client ISVs, but client code is changing, it has cloud interconnections now. What does a VAR look like these days, a solution VAR? What does an enterprise developer look like? What is the enterprise environment going to look like when it's transitioned from an on-premises data center to one that factors in both an on-premises data center and the cloud. Perhaps there would be some businesses, small to medium size businesses, that might shift completely to the cloud for their back end. But most major enterprises would have some kind of hybrid. So when we step back and look at tools, languages, application design patterns, operating systems, and runtimes, we kind of look at it and say: How will we design this for the way that the environment will shape over the next 5, 10, 20 years? As opposed to what does the web look like today, what are the capabilities today. I think Amazon has done a great thing in terms of opening people's eyes to the power of, coming from the ground up, what does it look like to make raw resources, raw VMs, or blobs, available to a developer. I think they've done all of us a great service, and themselves. Google's recent announcement, I think, is actually the inverse. It's done a good service in terms of looking at an individual developer and saying: "Hey, for a specific problem, what is a very simple way of getting into this cloud game with a relatively constrained pattern and model, but doing it in a fairly slick, seamless way." I think those are both interesting viewpoints and ultimately the answer that the broad developer audience wants will be a combination of those and many other things.

JU: Good. So in that context, we have just announced Live Mesh, and when I first saw it, I worried a little bit that people would see it in comparison to a lot of things which on the surface, it compares to. It can look like a FolderShare kind of thing, it can look like a screen-sharing kind of thing, it has those aspects. But in fact, this is one example of some platform-like capability for which those things are really trivial applications that have been layered on top. We can talk about Live Mesh, so let's talk about it.

RO: Live Mesh began with the perspective of saying, what is the environment that we are in today, and that we'll be in for the next who knows how many years. As users we're in a multi-device environment, and we need to cope with these many different devices. Each one of us at home ends up being a kind of system integrator, if you want to get simple media sharing scenarios done between devices at home. You might have different contact-sharing things between your phone device and other things that you are dealing with on your web or on your PC. If you're in a productivity context, you have document-sharing scenarios both among people and among devices.

Each one of use has had challenges, if we have multiple PCs and multiple devices, figuring out how to get the most recent version of that application installed on all the right devices that we're the system managers for. On the enterprise side, we've solved this quite well with things like SMS that lets an enterprise push things out to many desktops and manage desktops, but we haven't actually solved that problem for individuals. It hasn't been a huge pain point for individuals, but now it's becoming more of a pain point.

That's one aspect that started us down the path of Live Mesh. We basically said, the OS as it is right now, the OS for the phone, the OS for the desktop, the Xbox, the OS for a Zune, the OS for the PC, are all designed more or less to expose the resources of that device to developers and to users, but they are really not designed in concert with other devices. What is going on in the web is mostly done serving the web, and the browser is largely disconnected from those devices. If we were designing an operating environment for users or developers today, looking forward, it would probably look a little bit different. It would look like something that would bring those devices together for the end user. And so that is one thing that Live Mesh does. It brings together your devices. You use the web as a hub to claim your device. You securely identify yourself as an authorized user of this device. Multiple people can own a device as authorized users and each person can have many devices.

Once you've said that's your device, it enables many things. It enables centralized health monitoring and status reporting. It enables settings replication across your devices in computers where you think appropriate. It lets data flow among those devices, whether files and folders, or other things that I will talk about in a minute, like feeds. And it lets applications be configured and potentially licensed across your device mesh.

And in solving the problem of getting things to work across your devices, the same kind of technologies can be used for multiple people. So if you share a folder of documents, if you are working on a set of documents on your desktop with someone else, those same technologies that are used to synchronize that folder across devices can be used for me to share with you or other people. So from the user's perspective, we think that Live Mesh can really transform your experience with multiple PCs and things like your phone to make the experience very seamless in that way.

Now let me just come from the developer's perspective, Live Mesh is actually a platform. What you see with Live Mesh when you download it is a very small piece, from the user's perspective, of what it actually is, because it was built to enable innovation in a variety of ways. You can kind of think of what you see as the shell. If Windows or an OS has a broad sort of capabilities that is exposed by its APIs to developers, the shell, the command line of an OS or the Finder or the desktop within Windows is a thin exposure of that to users. For Live Mesh, file and folder synchronization is that small amount that gives the user a taste for the capabilities of this platform.

JU: You've talked with me before about a couple of distinct application patterns. I think one of them is going to be intuitively obvious to people because the folder and file synchronization thing is something that people already do. So people are going to kind of get that if you drop a thing here, it shows up there, and hopefully they'll be delighted to find out that subtler kinds of things than whole files and folders can also participate in that synchronization. And they'll be interested to see how they can then bring people into the equation, with sharing. All that I think is what people will get at first glance. I think what will be less obvious is the way in which websites can use Live Mesh to optimize the communication of stuff down to individuals and groups of individuals. Since that's less obvious maybe we should take a moment to spell that out.

RO: Sure. You can look at it from two perspectives. Live Mesh is a way of enabling rich applications on the PC to get their settings and their data across devices, as you just said. But it's also a way for websites to be able to efficiently extend their function down to a world of devices. The PC for sure, but also phones and other devices. One of the things that we inadvertently stumbled upon in Groove was that enterprises wanted to use this technology to help them extend the functions of their websites out to a world of devices. That isn't what Groove was designed to do. It was more designed as a peer sharing mechanism. So one of the things that Live Mesh is all about is essentially, from day one, providing a centralized infrastructure such that this platform that's on all of the clients goes to this one service in the cloud to manage, all under the covers, all the synchronization. Now the actual data may flow peer-to-peer, it might flow relayed through the cloud encrypted, but one thing that is for certain is that an arbitrary web site won't have to deal with the complexities of synchronization. They can develop an application, using technologies that they are familiar with -- web development technologies -- and develop a piece of that application that gets downloaded to the client, that has local storage synchronized with the web site, they can update the application and the updates get distributed transparently...

JU: Or maybe it's just data.

RO: Yep, could be data.

JU Let's talk about my bank's web site and my travel web site, two websites that I frequently do business with. In both cases there's data exchanged, and I would love for that data to be exchanged in a fully synchronized and reliable and transparent way. What you're saying is that both of those web sites, and any other of web sites that I transact with, can pretty straightforwardly get into the game of plugging their pipes into my mesh.

RO: That's right. They can plug their pipe into your mesh, and it's through mechanisms that most web developers these days are becoming increasingly familiar with, such as feeds. Some people might remember a few years ago there was a technology that we introduced, an extension to RSS called SSE (simple sharing extensions), that eventually matured -- with the help of the partner community -- into something we now refer to as FeedSync. It's essentially RSS and Atom extensions to a technology that was initially developed for publishing, where you have a list of items that get updated, and through a publish/subscribe mechanism, the updates get sent out. FeedSync extends that to make it bidirectional. You can essentially do crosswise subscriptions. I subscribe to you and you subscribe to me on the same feed. We can both modify it, and make sense of the results, and understand how conflicts are dealt with.

By using this very simple technology, we connect the web site to our cloud, our cloud to the clients, the clients to each other. It is just a very simple thing. The base model of what is an application within the Live Mesh environment begins with essentially a feed of feeds. One feed represents a logical thing that a site might be exchanging with the client. That's called a mesh object. It's a feed of feeds. A developer can new up one of these things, and its elements are other feeds. An application can develop as many feeds as it likes. Some of those feeds are hard-wired to be things like the list of members, or the list of devices in the feed, but then the application can develop many more.

JU: The way I'm thinking about it is that the sub-feeds are basically custom objects. If it's a calendaring application, those might be calendar events. In banking applications, they might be transactions. But the notion is that the same infrastructure that's synchronizing files and folders can also synchronize these custom objects in the same way.

RO: That's exactly right. In what they see today, if you open up a folder, what we would refer to as a mesh-enabled folder -- it's one of these mesh objects. And in essence every file within that folder is an element, it as an item within the feed. The file itself is the enclosure. The metadata of the file -- its name, its modified date and so on -- are a standard schema that represents the item. Then there's a news feed that you'll see on the right hand side if you open up one of these folders, that's another feed, and each of the entries in there is another item, and so on.

We expect that developers will develop feeds that suit the needs of their specific application, and we deal transparently with the synchronization of those elements. The user interface offers a very simple consistent way to help users manage conflicts -- if the application says that the user should be the one to deal those conflicts.

JU: There are a lot of interesting degrees of freedom here. My bank's website has a RESTful interface to this stuff, but so does my mesh client. In fact, I think people will be surprised and delighted to discover that you can hit the localhost with REST calls -- and that's putting stuff in, as well as getting stuff out.

RO: Right. We made a decision, from an API perspective, that developers would prefer to learn one way of dealing with the mesh, and that the tooling would be easier if we had one way of dealing with the mesh. So the web version of Live Mesh, what's running up in the web, and what's running on the client, are symmetrical and the same code. So on localhost, in a secure way, an application uses REST calls to invoke -- we call it MOE, the mesh operating environment -- or it calls cloud MOE to do what it needs to do.

JU: I think I can figure that out. [laughs]

So the synchronization piece is interesting. You've obviously been around this track a few times before. This time around, how is it different, how has it evolved from things you did in Notes or in Groove?

RO: Well one thing that's different is that I didn't build this software. I sponsored it, I had a good degree of input. But a very talented team, with talented leadership, formed and rose to the task. I sponsored it, and there is certainly a DNA trail you can follow from Plato at University of Illinois to Lotus Notes to Groove and now into Live Mesh. And I was fortunate to have the opportunity to interact heavily with that team, when I had the time to do so, which was right after I came on board, when I was still in the CTO role. But they took these base concepts and really ran with them, and developed it into a much richer thing than I could imagine.

But the DNA elements are the basic sync model, the basic interaction model. The biggest difference between Groove and Notes was that Groove embraced the concept of ad-hoc interaction much more in terms of inviting people into a shared environment. So those invitation models are essentially borrowed from Groove into Live Mesh. So if you are a Groove user, you will feel very comfortable with that model in dealing with Live Mesh.

JU: So, Mesh.com is the place to go to check it out but where do the developers find the SDK and everything they they need to know to actually work with it?

RO: We're bringing out the Live Mesh software right now because it's a preview, we need to begin getting user feedback, we need to begin testing the scale of the back-end. You can architect and plan these things but you can't actually just light them up at hundreds of millions of users overnight. So there's a progressive rollout that begins today. What you won't find on mesh.com is the developer kit. We're beginning a series of systems design reviews with smaller sets -- but increasing sets -- of developers over the course of the summer. The official rollout of the dev platform, and broad availability of the dev platform, would be at our PDC, our professional developer conference, this fall. So as a user, look at Live Mesh now. As a developer, stay tuned, look at the screencasts that we've done, they'll show what we can do from an application perspective, but really, come to the PDC, go to the PDC web site when it happens and play with it. Both from the perspective of extending a rich application to the web and to other devices, and also extending a website out to take advantage of the power of Windows.

JU: This is been extremely useful. Thanks, we appreciate it.

RO: It's been fun, thanks.