So, this post is about what COM gets right, and therefore what we need to copy from it :)

I do believe that we need to copy some things from it. COM on Windows has been a great success in terms of code sharing. When the Jabber team wanted Windows clients, Peter Millard wrote JabberCOM. There were no arguments over what language to use, what dependencies it could have, or how to expose the API - it was written in Delphi (a dialect of object pascal) exposed via COM and that's how it was used. End of story. Contrast this to the stupid and childish arguments that happen in the community over trivial matters of code style and utility libraries, and you see why while the rule of a dictator may be hated and unjust, it is at least somewhat orderly.

The current scenario on Linux where libraries are written in C then bound into other languages has a few advantages, but also a few major disadvantages.

The biggest advantage is that you do tend to end up with a reasonably sane, well integrated API that follows the idioms of the platform you're using. For instance, pygtk does not require you to make calls like CreateObject("{3a36cb61-e38a-43b3-aa0d-407e7cfb2168") in order to construct a window, you can just do "import pygtk" like every other native Python library. This can be done regardless of the design of the underlying API.

It does however have many disadvantages (obviously, or I wouldn't be saying we need something better). For starters, wrapping is an manhour intensive process. The bindings have to be created, then maintained. It has to be done over and over again for each language. Worse, this software doesn't actually do anything, it is "metasoftware", that simply helps us write other software better. The more time we spend writing this metasoftware, the less time we have for software that solves end user problems.

Perhaps one of the biggest disadvantages is that while theoretically you can bind from any platform into any other, in practice all the experience and tools is in going from C to somewhere else. It's common to find bindings for a library written in C to Python, but rare (in fact I've never heard of one) going from Python into C. They are both theoretically possible, it's just that one is unexplored territory so the conventional wisdom is that if you want to share code, it must be written in C.

Clearly this attitude is not productive. C is not an especially efficient language to work in. Higher level languages can be used to get things done a lot quicker, and while Python (and maybe in the future mono) is taking off for applications the same is not true of software components.

So what do we need in order to share software components between "platforms" (which for want of a better word is the term I'll use to mean C vs C++ vs .NET vs Python and their associated standard libraries)?

The basic requirement is a shared object model. An object model tends to consist of a) a set of agreements on how things should be done and b) some sort of "magic", by which I mean opaque implementation details. COM for instance is roughly equal parts agreements and magic - COM components must use the COM reference counting model, must implement IUnknown and so on, however they don't necessarily have to rely on the CoCreateInstance() activation registry magic. While IDL is a formalized agreement, the code that turns that agreement into code you can invoke from your chosen platform is magic.

The magic to agreements ratio of object models varies wildly. The C++ object model for instance is almost entirely based on agreements, for instance between compiler vendors on the ABI to use, and as embodied in the C++ language specification. The lack of any ABI agreements on Windows was one of the driving forces behind the uptake of COM. From the users perspective a lot of this takes place automatically, but they could if they wished format the ABI themselves (to construct vtables on the fly for instance) - it's just that nobody does it, because it's so complex.

In contrast, the Python object model is almost entirely magic. There is only one canonical implementation of the Python object model, the one produced by the Python project. Alternative implementations such as found in Psyco tend to be a little buggy. The advantage of a magic based object model is that you're not tied down by standards, and you are therefore much freer to extend or improve it. Magic is also a lot easier to work with, you can rely on quirks of the magic to get things done.

In order to share objects between platforms a common ground is needed, in other words you need a shared object model. In the case of COM, this model is very simple, it can hardly even be called an object model at all. CORBA is rather more advanced but rather more complex.

Of course COM does not just provide an object model. It also provides network transparency and thread safety to its components. I'd argue that these things are actually entirely separate issues that should not be glued onto a shared object framework simply because it's sort of possible, though there may well be a separate, clearly defined way to get these features in the context of the framework. The overheads and complications that seep into COM because of the location transparency generally aren't worth it, IMHO.

We don't have very many possibilities here, unfortunately. There are at least three different shared object models that we could use in the free software community (and that have a slight chance of being accepted). Next time I'll go over what they are, and which I personally would choose.

Perhaps in future once autopackage is up and running, I might try my hand at hacking one of them up. We'll see how it goes.