You are viewing pphaneuf


Last weekend, I got my residency permit turned down, which, to make a long story short, means that we'll be heading back to Canada. Seems like I was misdirected by the Consulat de France in Montreal, and from what I hear, it seems to be something they've done a few times (azrhey worked in a place here where they hire a lot of foreigners, due to language skills).

So, it looks like I'm going to be looking for a job back in Montreal.

My weapons of choice are C++ and Perl, but being a Unix/Linux hacker, of course, I am not limited to those, they're just the ones I'm most deadly with. I am comfortable with meta-programming (mostly, but not limited to that of C++ templates), continuations/coroutines, closures, multithreading, as well as event-driven state machines. I am quite effective at code refactoring, particularly in strongly typed languages, where I can use the typing system to my advantage.

I am deeply intimate with Unix/Linux, mainly in the area of network programming (sockets, networking protocols, other forms of IPC). On Linux, I am quite familiar with a number of the high-performance APIs. I have a deep knowledge of the HTTP protocol (and some of its derivatives). I have experience writing Apache modules. I know the difference between bandwidth and latency (and wish more people did too). I have some experience with developing distributed software. I have a higher-than-average knowledge of ELF and Mach-O binary formats, particularly of how symbol resolution works. I know a good deal about component software (dynamically loading modules, for example), and ABI stability issues. While I am not a master at it, I have some Linux kernel development experience as well. I know what make is doing, and why.

Finally, I also have some experience doing project and release management, where I feel I did a pretty good job, and would certainly like to do more of it. I am familiar with the free and open source software community, belonging to a number of projects, including some that were part of my work.

Change is the only constant

Philip Van Hoof (also known as my evil twin, not so long ago, thought his Tinymail API was frozen, but ended up having to change it anyway.

It's been said many times, but there it is again: change is the only constant.

When I tell people about XPLC, they often think that it's about dynamically loading plug-ins, extending applications at runtime. But it's not really that. What it is about is interfaces.

It just so happens that interfaces are a requisite for plug-ins, but really, they are everywhere. An API is an interface, as is an ABI. It's just that the first obvious use for an interface is plug-ins, extensions, or whatever dynamically loaded piece of code.

Some project are very aware of their interfaces, glibc or libpng for example. The former uses all sorts of ELF tricks (like sonames and symbol versioning) so that code linked against an earlier version can still work correctly with a newer version (this is called backward compatibility). The latter is careful to never remove or change the semantic of existing functions, only adding new functions while providing a way of knowing whether the functions are available for your use. Some, like GTK+, have taken different approach, where they made sure that incompatible versions can be installed in parallel (the downside being that a bug fix in the newer, still supported version, will not fix applications still using the older version).

What does XPLC bring to the game? It helps manage all of these things, in a portable way. Those ELF tricks I mentioned, they do not work on platforms that do not use ELF, like Mac OS X or Windows. Also, the technique used for defining interfaces not only allows backward compatibility, but also forward compatibility, where an application that only uses a subset of an interface can easily use an older version of the interface (that is still supported by the library implementing it, of course) on purpose, so that its runtime requirements are lesser. This is not possible at all with the ELF symbol versioning, for example.

A library providing its interfaces using XPLC can even make incompatible changes in its interface in a new version (such as changing the semantics or replacing a function by another), while still maintaining backward compatibility, admittedly at the cost of providing adapter glue. Some people seem to think that you have to provide this glue, but it is left at the discretion of the library's implementers (consider it's also possible to stack adapters, making things work, but likely an extra cost in runtime efficiency). If we think back to the GTK+ approach of parallel installation, this means that fixes to the library will fix the users of the old interface just as much as those of the new one. There is a downside, of course, in that this adapter glue is more code, and that more code brings "opportunity" for more bugs, but still, the glue can also be fixed in a newer version, without breaking the interfaces.

When ones considers the possibility of security bugs in older, unmaintained versions of a library, the only two ways would be to update all the applications to use the new version of the interface (which is impractical, for clear reasons, anyone needing a reminder can only look at XMMS, still widely used, despite many attempts at killing it) or to keep on updating the older version. With XPLC, the adapter glue can be fixed, and since the applications are, in fact, using the new version of the library, they can actually migrate to the newer interface incrementally, so it can be done without major disruption or the heavy burden of conversion work.

There are also sometimes optional modules in a library, that are controlled by compile-time options (to the "configure" script, for example). XPLC interfaces are discoverable, meaning that you get the best out of both strong typing and dynamic typing: you can explore the interfaces an object implements dynamically, and when it tells you that it is indeed supported, it is a strong, binding contract.

So, in summary, with XPLC interfaces, one can get:

  • A stable ABI.
  • Backward compatibility, even through "incompatible" changes.
  • Forward compatibility, allowing application writers to easily target older version.
  • Opportunity for incremental migration from older to newer APIs.
  • Discover optional modules at runtime, without requiring extra shared objects.

All of this is in the simple case of a single implementation of a given interface, but as Philip is demonstrating, it only starts there. He uses interfaces to let users of Tinymail provide their own alternative bits and pieces, mixing and matching as the task at need requires. Not to mention unit testing, language neutrality (including scripting), and so on...


Latest Month

March 2009


RSS Atom
Powered by
Designed by Lilia Ahner