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.

Havoc, I was not trying to debate. I agree with your qualifications on your second post about SOAP, in fact depending on the task or depending on the day I would choose one over another, I just took exception at the "masochist" comment. I have no desire to debate the SOAP vs REST discussions again, they were long and boring two years ago and they likely will be long and boring today.

That being said, my post about building the communications infrastructure on the desktop over HTTP was quite serious. I have been having this discussion over chicken schwarmas at lunch for months. I was not joking, nor was I trying to ridicule the discussion, I really believe that there is a lot to win with this model. The more I thought about it, the more sense it made to have applications speak HTTP on the desktop.

The discussion over SOAP and REST reminded me that I had long postponed a blog entry on my thoughts on the subject.

Will try to cook up a prototype activator.

Am glad that Havoc brings up the simplicity of jamming and pulling XML from a socket:

Miguel, that's cool, I know SOAP (with a library) doesn't involve a ton of application code. My point is more that (to me) it's just not worth learning about for this sort of thing. If you want to get a couple of pieces of data on an Amazon product you just do "get url contents" and "stuff into XML parser" and "grab the Item node" and that's about it. All programmers already know how to download a URL and pull out an XML node, and being able to try out requests in the browser by editing the address in the location bar is pretty useful. "REST" is just very conceptually simple and requires no ramp-up time, even if it involves a couple more lines of code.

Recently I have been considering the implementation of a system that would replace D-BUS and CORBA with a simple HTTP framework.

At the core of such replacement there is an activation and arbitration system running on a well known location, for example: http://localhost:123/. This can be an Apache module or a custom built HTTP server.

The daemon, very much like our existing activation systems (bonobo-activation and d-bus) has a list of services that can be started on demand and provides assorted services to participants.

When an application starts, it registers itself with the local arbitration daemon, it does this with a RESTful call, lets say:

http://localhost:123/registration/id=f-spot&location=http://localhost:9000/

Where "f-spot" in this case is the name of the application, and "localhost:9000" is the end point where F-Spot happens to have an HTTP server running that exposes the F-Spot RESTful API.

A client application that wants to communicate with F-Spot always contacts the well-known end-point:

http://localhost:123/app/f-spot/request

The arbitration daemon merely returns an HTTP 303 result pointing to: http://localhost:9000/request. The http client library already has support for this redirection.

If F-Spot was not running, the arbitration daemon would look into a special directory that lists the available applications. The file could be called "f-spot.service" and it would describe how to launch f-spot, very similar to the way d-bus does it:

	[Service]
	Name=f-spot
	Exec=/opt/gnome/bin/f-spot
	

The request comes in on http://localhost:123/f-spot/request, the activator launches f-spot, f-spot registers itself using the previously discussed call, a redirect is then sent to the client and you are done.

To use this system as a message bus, in the same spirit as d-bus, you merely connect and listen to another well known-end point: http://localhost:123/bus/event-name. The connection is never closed by the server and clients keep reading data from this stream.

To push information into the bus, a POST request is done http://localhost:123/bus/event-name. The contents of the POST are then delivered to all the clients that are listening on the endpoint.

The format and protocol for the information that flows on that particular HTTP request as REST is up to the creator, users would have to follow that format. For example it could be one line at a time, or it could be a url pointing to the full message.

As for the security of this system, it should use a mechanism similar to what we have used in the past with Bonobo Activation: a randomly generated password is generated and stored on the file system in a well known location, and private location (~/.config/private/something).

The security process is the only component that requires a little bit of code. The rest can be implemented just with an HTTP client and the HTTP server for those providing information. A client application would only needs something like this:

	FILE f = popen ("http-get-key");
	fgets (password, sizeof (buf), f);
	close (f);
	

The benefits I think are multiple:

• HTTP is a well known protocol.
• There are plenty of HTTP client and server implementations that can be employed.
• The protocol can be as simple or as complex as needed by the applications. From passing all the arguments on a REST header as arguments to the tool-aware SOAP.
• HTTP works well with large volumes of data and large numbers of clients.
• Scaling HTTP is a well understood problem.
• Users can start with a REST API, but can easily move to SOAP if they need to.
• HTTP includes format negotiations: clients can request a number of different formats and the server can send the best possible match, it is already part of the protocol. This colors the request with a second dimension if they choose to.
• Servers can take advantage of HTTP frameworks to implement their functionality on the desktop.
• It is not another dependency on an obscure Linux library.
• The possibility of easily capturing, proxying and caching any requests.
• Redirects could be used to redirect request to remote hosts transparently and securily.
• And finally, makes the desktop "Web 2.0 ready" :-)

HTTP on its own has plenty of fantastic advantages that today we are bound to reimplement with things like D-Bus or live without them.

The implementation of this infrastructure is trivial. All I need now is a name for the project.

The same version of the C# program written in Boo:

	if len(argv) < 3:
		print "Usage is: associate-id token searchterm"
		return
	
	search = AmazonSearchService ()
	kr = KeywordRequest (keyword: argv [2], tag: argv [0],
		devtag: argv [1], mode:"books", page: "1", type: "lite")
	
	for detail in search.KeywordSearchRequest (kr).Details:
		print "Product: ${detail.ProductName}"
		if detail.Authors != null:
			print "Authors: {0}", string.Join (", ", detail.Authors)
	

To build:

	$ mcs -target:library AmazonSearchService.cs -r:System.Web.Services
	$ booc am.boo -r:AmazonSearchService.dll
	

To run:

	$ mono am.exe YourAssociateID YourToken YourQuery
	

Havoc claims on his "Adventures in Web 2.0" post that Amazon has a SOAP API "for masochists". What exactly is difficult about SOAP exactly?

It took me longer to register with Amazon and obtain my developer key after reading his post than it took me to write a small C# program.

Step 1: Google for "Amazon WSDL", pass the link to the wsdl compiler:

	$ wsdl http://soap.amazon.com/schemas2/AmazonWebServices.wsdl

Step 2: register with Amazon, obtain your IDs.

Step 3: write trivial program:

using System;
using System.Web;

class X {
	static void Main (string [] args)
	{
		if (args.Length != 3){
			Console.Error.WriteLine ("Usage is: amazon amazon-affiliate-id amazon-access-key keyword");
			return;
		}
		
		AmazonSearchService s = new AmazonSearchService ();
		KeywordRequest kr = new KeywordRequest ();

		kr.keyword = args [3];
		kr.tag = args [0];
		kr.devtag = args [1];
		kr.mode = "books";
		kr.page = "1";
		kr.type = "lite";
		
		ProductInfo pi = s.KeywordSearchRequest (kr);
		foreach (Details detail in pi.Details){
			Console.WriteLine ("Product: {0}", detail.ProductName);

			if (detail.Authors != null)
				Console.WriteLine ("Authors: {0}", string.Join (", ", detail.Authors));
		}
	}
}

Step 4: Compile the sample code, and include the generated client code from WSDL, link with the Web Services library:

	$ mcs am.cs AmazonSearchService.cs -r:System.Web.Services

	

Step 5: Run:

	$ mono --debug am.exe myassociate-id  my-key "bugs in writing"
	Product: Writing Solid Code: Microsoft's Techniques for Developing Bug-Free C Programs (Microsoft Programming Series)
	Authors: Steve Maguire
	Product: BUGS in Writing: A Guide to Debugging Your Prose (2nd Edition)
	Authors: lyn dupre
	Product: The Writing Bug (Meet the Author)
	Authors: Lee Bennett Hopkins, Diane Rubinger
	Product: BUGS in writing: A guide to debugging your prose in mathematics ; taken from BUGS in writing a guide to debugging your prose
	Authors: Lyn DupreÌ
	Product: Raewyn's Got the Writing Bug (Voyages)
	Authors: Raewyn Caisley, Brian Gilkes
	Product: The Millennium Bug.(Brief Article)(Poem) : An article from: New Statesman (1996)
	Product: Hooking the Nose of the Leviathan: Information, Knowledge, and the Mysteries of Bonding in The Gold Bug Variations. : An article from: The Review of Contemporary Fiction
	Product: Mai-Lee's bug disaster. (poem) : An article from: U.S. Kids
	Product: Don't Bug Me!
	Authors: Gillian McHale
	Product: All this talk about the millennium bug is sheer techno-paranoia, isn't it? But then again.... (year 2000 furor) : An article from: New Statesman (1996)

	

I concede that using SOAP with printf and jamming the output down a socket is harder than using a toolkit. But jamming down printf-generated XML down a socket without having a complete HTTP client stack implemented is asking for trouble on both counts anyways.

Alvaro and US Airport Security

Alvaro complains about being treated like a criminal in US airports. I would argue that every time you cope with "security" you are treated like a criminal, and this is not limited to US airports.

Alvaro just came from Mexico, where every person entering the country is randomly subject to a full property search on arrival. The situation is no different in Europe. If you are white or European they will mostly leave you alone, but if you look remotely like arriving from Africa you get a very different treatment in immigration and customs.

My point is merely that singling out the US airports for this treatment is not really fair. Annoying, perhaps, but with international travel you must be ready to cope with these kinds of things.

Lluis has released a new version of MonoDevelop, there are plenty of new features in this release. The release notes are here.

• A Welcome Page: a starting point for your ongoing projects.
• New component-based architecture for the IDE. For details see the Architecture Overview.
• New Add-In manager to install, update and remove plugins for the MonoDevelop IDE.
• A command-line build tool, so you can integrate MonoDevelop projects into your batch compilation process.
• Smartindent for C# and Boo languages.

This release is the results of many months of work where he rearchitected MonoDevelop to be a modular IDE.

The core of MonoDevelop basically offers a framework for plugins and third-party components. The framework includes a system to install, upgrade or remove plugins and little more. For instance it does not have any notion of projects.

All the functionality of the IDE has been moved into its own modules that are layered on top of it.

The new Welcome Page.

Radek Doulik talks about his work on his Cairo-based Canvas for OpenOffice and shows the quality difference.

He also posted his slides for his presentation.

Office File Formats

Novell will be sending some folks from our Open Office team to the newly created ECMA TC45 working group. We hope to determine if the standard will be open enough and the details complete enough to allow for interoperability.

Imendio has checked into CVS their Gtk for OSX port.

Robert Fisk lecture in LA is available in MP3 format here.

Robert is an incredible story teller.

In this talk he describes some of his experiences as a journalist on the Middle East in the past twenty years and why he started to write his new book "The Great War of Civilization".

Packed with anecdotes. The parallels between the British occupation of Iraq and the new occupation are incredible.

Been loving the US version of "The Office", the awkward moments are all there.

I also find "American Dad" hilarious. My love is divided between the fish and the alien.

A few weeks ago I purchased a 24" flat screen from Dell. The sole purpose of this monitor is to run F-Spot to manage my home photo collection. Today I completed the F-Spot setup at home.

Noam Chomsky on the debate about intelligent design:

To proponents, intelligent design is the notion that the universe is too complex to have developed without a nudge from a higher power than evolution or natural selection.

To detractors, intelligent design is creationism --- the literal interpretation of the Book of Genesis --- in a thin guise, or simply vacuous, about as interesting as "I don't understand" as has always been true in the sciences before understanding is reached.

Accordingly, there cannot be a "debate."

Robert Fisk on the rebranding of torture:

What Americans do to their prisoners is "abuse" and there was a wonderful moment last week when Amy Goodman, who is every leftist's dream, showed a clip from Pontecorvo's wonderful 1965 movie "The Battle of Algiers" on her Democracy Now program. "Col. Mathieu" -- the film is semi-fictional -- was shown explaining why torture was necessary to safeguard French lives.

Then up popped Bush's real spokesman, Scott McClellan, to say that while he would not discuss interrogation methods, the primary aim of the administration was to safeguard U.S. lives.

U.S. journalists now refer to "abuse laws" rather than torture laws.

Molly Ivins has her own take:

I have known George W. Bush since we were both in high school -- we have dozens of mutual friends. I have written two books about him and so have interviewed many dozens more who know him well in one way or another. Spare me the tough talk. He didn't play football -- he was a cheerleader. ''He is really competitive,'' said one friend. ``You wouldn't believe how tough he is on a tennis court!''

I tried to track down Robert Fisk as he tours the US but the only confirmed dates that I have are for California this weekend and I do not feel like crossing the country. If you happen to know of any dates somewhere closer to the East Coast, please drop me an email.

Norman Finkelstein is talking on Thursday in Boston. Details are available here. Norman is the author of the "Beyond Chutzpah" and "Israel-Palestine Conflict" books. Am pretty psyched.

Massi posted his fast implementation of Dead Code Elimiation for the Mono runtime.

This is an optimization that we can hopefully enable by default, as opposed to the more expensive SSA-based optimizations.

This is the first on a series of optimizations patches that Massi is completing.

El presidente Fox y su cabinete, nada más dan pena ajena. Que verguenza, y es que es una tras otra. Deberían de tener un examen de admisión.

Ese es el problema de elegir a alguien que bajaron del cerro a tamborazos.

I was reading the leaked memos from Microsoft and as I was reading the first few paragraphs, I could not stop thinking that nobody on their right mind writes internal company memos like this. Nobody puts this kind of history background.

Consider the recipients: "Executive Staff and Direct Reports; Distinguished Engineers".

I could not stop thinking that these memos were written to be leaked. They read like ads.

Update: Alex points out that Cringely made the same observation. The difference is his article is actually interesting. Here is a tidbit:

But I have to say that Gates or Ozzie or whoever actually wrote these documents has done a very effective job of differentiating the company roles in a way that makes Google appear to be the bad guy, and Microsoft appear to be the good guy. Google is going to develop and deploy Internet services while Microsoft is going to ENABLE the deployment of such services BY ITS DEVELOPER PARTNERS. This makes Google the would-be monopolist.

Looking deeper, though, we see that the only way Microsoft can achieve its vision is by continuing to own the platform. They want us to be GRATEFUL, in fact, that such an enlightened outfit is running the store. And this will work to an extent, but only to an extent. Then what happens? All hell breaks loose as Microsoft again changes the game. Here's how: read the rest

The Italian documentary about the use of chemical weapons in Fallujah can be downloaded here.

A guy which sounds pretty upset about it is here.

Robert Fisk described the use of Phosphorus bombs on the civilian population of Beirut, you can read a couple of pages with Google Print: here.

Update: A reader points that the official page for the RAI documentary contains more download options and formats. The page is here.

Jakub has done a screencast of the new tagging feature in F-Spot.

Nat recently implemented tag-typing for F-Spot, our new photo management software. For those of us with large picture collections this is probably one of the best interfaces for tagging.

See Nat's post here and his latest patch here.

Send copious amounts of email to Nat until he does a screencast of this new feature. You have to see it to appreciate it.

On the hacking side of things, the beauty of this patch is that it was coded in two afternoons after long busy work days for Nat.

The Washington Post yesterday ran an article that claims that the CIA has a network of secret prisons where they have been incarcerating suspects. The CIA denies such prisons exist:

The CIA has been hiding and interrogating some of its most important al Qaeda captives at a Soviet-era compound in Eastern Europe, according to U.S. and foreign officials familiar with the arrangement.

The secret facility is part of a covert prison system set up by the CIA nearly four years ago that at various times has included sites in eight countries, including Thailand, Afghanistan and several democracies in Eastern Europe, as well as a small center at the Guantanamo Bay prison in Cuba, according to current and former intelligence officials and diplomats from three continents.

...

Mid-level and senior CIA officers began arguing two years ago that the system was unsustainable and diverted the agency from its unique espionage mission.

"We never sat down, as far as I know, and came up with a grand strategy," said one former senior intelligence officer who is familiar with the program but not the location of the prisons. "Everything was very reactive. That's how you get to a situation where you pick people up, send them into a netherworld and don't say, 'What are we going to do with them afterwards?' "

Billmon weights in:

The plot line should be familiar to students of the Abu Ghraib atrocities. Interrogation tactics originally developed and/or authorized for use against "high value targets" at Guantanamo were exported first to the broader Gitmo population, and then to Iraq, where they were put into mass production by a group of half-trained or entirely untrained intelligence officers and MPs. The result was an entirely predictable moral and political disaster -- one which may have cost the United States whatever slim chance it had of establishing a popular, pro-Western government in Baghdad.

Likewise, the CIA's mini-archipelago seems to have grown like a poisonous weed in the absence of any coherent strategy for fighting Islamic terrorism, other than the initial impulse to hunt down the "evildoers." But now, like a dog who chases cars and actually catches one, the war cabinet faces the awkward question of what do with its secret prisoners and their secret prisons, even as the media finally starts to peel back the layers of secrecy. This story is going to cause something close to panic in more than one Eastern European capital, I suspect, and a relatively quick exit from that Soviet-era "compound." Where will the CIA take its human contraband now?

It seems to me that the Cheney administration has been trapped -- both by its ostentatious rejection of the "law enforcement" model of counterterrorism, and by its complete, willful failure to understand the limits of hard power and the steadily rising importance of soft power in a struggle that will last years, if not decades. Policies based on the adrenaline rush of war fever (circa 2002) were never likely to be sustainable. They also haven't brought us any closer to capturing Osama or prevented the transformation of Al Qaeda from an organization to a movement, one that is much more difficult to fight with dirty war tactics.

In other news, Mexico joined the International Criminal Court which upset a few people in the US:

Washington had warned Mexico that if it ratified the ICC and refused to sign an accord exempting U.S. nationals from the court's jurisdiction, it would cut 11.5 million dollars in funding from aid programs for fighting drug trafficking, according to human rights groups. The amount is equal to almost 40 percent of the economic aid Mexico receives from the United States.

Nat makes an observation about the Linux Desktop.