<script>
$(document).ready(function(){
$( '#target' ).fold();
});
</script>
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.
This was the concluding paragraph in a post by Danny Thorpe of Microsoft (and formerly Google).
His post is itself a rebuttal on Dare’s article: Live Framework (LiveFX), Is it Microsoft’s GData or Something More?:
A number of LiveFX’s additional features such as synchronization and resource introspection which have no analog in GData are fairly interesting and I wouldn’t be surprised to see these ideas get further traction in the industry. 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.
Danny answers:
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.
The Live Framework local LOE is 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.”
I am trying to wrap my mind around this all myself :)
Graphics in Google ChromeGoogle Chrome uses a library called Skia, which is also the graphics engine behind Google’s Android mobile OS. The two projects share code that implements WebKit’s porting API in terms of Skia. Google Chrome also uses Skia to render parts of the user interface such as the toolbar and tab strip. I’m going to talk about some of the history that led us to choose Skia, as well as how our graphics layer works.
We moved the I/O onto a number of background threads which allow the user-interface to proceed asynchronously. We did this for large data sources like cookies, bookmarks, and the cache, and also for a myriad of smaller things. Writing a downloaded file to disk, or getting the icons for files in the download manager? The disk operations are being called from a special background thread. Indexing the contents of pages in history or saving a login password? All from background threads. Even the “Save As” dialog box is run from another thread because it can momentarily hang the application while it populates.Content, not ‘Chrome’
To achieve the streamlined feel we were after, we knew we would have to cut some things, and while we had our own intuitions about what was and wasn’t useful in current browsers, we had no idea how those ideas matched to reality. So in typical Google fashion, we turned to data; we ran long studies of the browsing habits of thousands of volunteers, compiled giant charts of what features people did and didn’t use, argued over and incorporated that data into our designs and prototypes, ran experiments, watched how our test users reacted, listened to their feedback, and then repeated the cycle over and over and over again.
Even the the more subtle parts of our first-level UI were subjected to similarly intense scrutiny - “what shade of blue best suits XP users”, “should the tabs start 18 or 19 pixels below the top of the window?”, “what’s the correct offset between our buttons?”. The answers to these questions were debated and tested for our entire development cycle, and we saw that opinions consistently differed greatly depending on whether we had been Windows 3.1, OS7 or even NeXT users and developers.The Google Chrome Sandbox
Google Chrome’s multi process architecture allows for a lot of flexibility in the way we do security. The entire HTML rendering and JavaScript execution is isolated to its own class of processes; the renderers. These are the ones that live in the sandbox. We expect to work in the near future with the plug-in vendors to securely sandbox them as well.
[Disclosure: I work for Google on the Open Web Advocacy team]
We heard from Will of the Psych Desktop project as he ran across our coverage of other Web desktop apps. He shared with us his project that is part of the Dojo Foundation which you can check out here.
He had some good thoughts, so I thought I would pass them along below:
Psych Desktop is an open source web desktop licensed under the AFL. We're a part of the Dojo Foundation, and have been around for around two years I believe. We're going to rename the project as Lucid when we finish our new site.Anyways, there are two main ideas behind Lucid. The first is that we aren't just building a clone of a desktop environment, but rather a desktop that was built for the web. For example, in 1.1 we plan on providing an alternate UI made for mobile devices such as an iPhone. Another example of what we want to accomplish would be a photo manager that would easily allow you to publish photos to a public photo gallery. We also want to do the typical things, like a word processor and email, but that's not the main idea behind the desktop.
The second idea behind it is that we should provide a nice, clean set of APIs for developers to use in their apps. For example, we've got a Registry that is based off of a dojo.data store, so you can plug it directly into a dojox.grid.DataGrid, and you instantly have an editable grid that writes back to the store. Another neat API is the crosstalk API, which allows intercommunication between users. The Messenger app is using this. There's also a sound API that can be used to playback audio. The apps are written in javascript, and don't require any server-side code at all. And of course, there's also a filesystem.
Right now we're in beta, but we're coming close to our 1.0 release. There's still a bit of work to be done, but it's stable enough for developers to start playing with it. 1.1 is going to be a lot more innovative, but I think 1.0 will be good starting grounds for our expedition.
It is cool to see the Will is passionate about the area and is "in it for the long term."
