by Miguel de Icaza

Just got back from watching Syriana. Loved it.

Posted on 12 Dec 2005

Human Development Trends

by Miguel de Icaza

Various statistics of human development trends in flash-tutorial form here

Posted on 10 Dec 2005

Harold Pinter's Nobel Prize Lecture

by Miguel de Icaza

A transcript is available here.

Political language, as used by politicians, does not venture into any of this territory since the majority of politicians, on the evidence available to us, are interested not in truth but in power and in the maintenance of that power. To maintain that power it is essential that people remain in ignorance, that they live in ignorance of the truth, even the truth of their own lives. What surrounds us therefore is a vast tapestry of lies, upon which we feed.

Posted on 08 Dec 2005

Mono goes to Munich

by Miguel de Icaza

I will be in Munich this week. Drop me an email if you want to meet. My schedule is a bit compact, but if you are interested you can join me and others for lunch or dinner Wednesday, Thursday or Friday.

Posted on 06 Dec 2005

Jonathan Chambers Screenshots COM in Mono

by Miguel de Icaza

Jonathan has posted a screenshot of his COM support for Mono. The sample shows Mono launching Excel with COM interop.

Check Jonathan blog for more information on his effort to support COM and its variants in Mono.

Posted on 03 Dec 2005


by Miguel de Icaza

My friend Xavi which is a sports instructor and also a circus performer got interested in Linux and free software a few years ago. He decided to learn C#, Gtk# and create his first GUI application some time ago and has now shipped it.

His application is ChronoJump. Its interesting because he was the first user for the Gtk# port of NPlot.

He also built some custom hardware to take the measurements:

Some NPlot Graphs.

Web report generation.

Hardware prototype.

More screenshots are here.

Posted on 02 Dec 2005


by Miguel de Icaza

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.

Posted on 27 Nov 2005

The Web Desktop

by Miguel de Icaza

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.

Posted on 27 Nov 2005

PlanetGnome observations

by Miguel de Icaza

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

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");
		AmazonSearchService s = new AmazonSearchService ();
		KeywordRequest kr = new KeywordRequest ();

		kr.keyword = args [3];
		kr.tag = args [0];
		kr.devtag = args [1];
		kr.mode = "books"; = "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.

Posted on 26 Nov 2005


by Miguel de Icaza

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:


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:


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:


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.

Posted on 26 Nov 2005

« Newer entries | Older entries »