The Web Desktop

As a follow up to yesterday's web-based desktop communication engine, I wanted to comment on a few ideas that we have been bouncing around.

Clearly the HTTP end-points on desktop applications would be useful to invoke an arbitrary set of methods on each application. I envision a system in which we can remotely manipulate desktop applications through HTTP. The same idea that I pitched a few years ago on top of CORBA.

The difference this time is that writing the client code is trivial, unlike the previous attempt where writing the client code to talk to a CORBA server was very difficult.

But in addition to this HTTP-based RPC interface, it would be nice to make the GNOME desktop Web-Aware.

Let me explain with a few use cases that we have been discussing at Novell:

Photo Sharing: A common household issue that I face is when I import pictures from a party into my F-Spot photo management program.

Here is where the problem arises: people want to look at the pictures right away, or they want copies of the pictures, or they want me to tag them or annotate them. All of those at once.

I hear you say "Post them to Flickr", well that would be fine except that the informed in the audience will demand a full resolution version. They will hand you an email address and demand that a bunch of pictures be emailed. Emailing is a drag, because more than a handful of high-resolution pictures is a drag as they typically bounce.

I could export to a folder and then scp the files over, but thats just because am a beautiful and unique snowflake. Other non-hacker types might not be able to pull the scp trick.

A few people have suggested to use the photo sharing protocol that iPhoto has. The problem is that a custom protocol for photo sharing requires photo-sharing-aware applications. And these applications are not as ubiquitous as a web browser is.

The Solution: F-Spot coult have a "File/Web Share" which would basically run an HTTP server. In the particular case of F-Spot it can just embed our embeddable web server and expose the pictures with an ASP.NET application.

By doing this, my wife and friends can use their laptops to browse the pictures, email them, print them or send them around right there.

Music Playback: Today I use Banshee as my media player. I have it available at home on my large music repository and on my laptop with a few songs that I carry with me.

Again, I would like to have a "File/Web Share" option that I could use at home to play music from any room in the house from a laptop. Or when am traveling let others listen to interesting music from my laptop.

For this particular case, a general purpose web interface can be cooked, and the media playback could be a Flash-based MP3 player (these are very easy to produce with FlashMX).

Web Serving It is not necessary for the applications to embed a web server. If embedding a web server is complicated they can just launch an external web server.

Mono based applications have a couple of choices: they can embed a raw HTTP server using HttpListener (available in the 2.x profile on trunk) or they can embed directly XSP which would let them host ASP.NET pages with little or no work.

Multiplexor: In both cases the HTTP-based multiplexing system that I described before can be used by remote users. As far as they know the url will always be "http://machinename:123/application/frontend" or something like that. The routing system will merely send an HTTP 303 redirect to the correct port.

The multiplexing system is not required, is merely cute.

Summary: a Web-ready GNOME desktop would have applications expose two HTTP-based interfaces: an HTML one for users and a raw HTTP interface for applications.

A web-aware desktop is not tremendously revolutionary, but it adds a little bit of convenience. A set of HTTP-accessible interfaces will make our desktop more scriptable than it currently is.