Thoughts on Thrift and D-BUS - Journal of Omnifarious
Feb. 22nd, 2008
08:30 pm - Thoughts on Thrift and D-BUS
I've been thinking about Thrift and D-BUS ever since I made this post: Java and XML, bad tastes that are worse together. And then I followed up with a reference to my paper: why CORBA and other forms of RPC are a bad idea.
Those, of course, sparked a lot of discussion. Questioning Java and XML, the darlings of 'Enterprise' computing, would hardly pass without comment. It provoked even more of a strong reaction than I'd expect I'd get from questioning AGILE methodologies.
I had to think carefully about my enthusiasm for these two things, and I've reached some conclusions...
First, I like D-BUS a lot better. The problem domain involves communications between processes on a single computer. Context switch overhead is a big deal here, but latency isn't. Also, many encoding issues are greatly simplified in this sort of environment, though D-BUS handles those well regardless.
There are several things I like about D-BUS. There is a consistent naming scheme for referring to D-BUS objects and interfaces. Interfaces are generally expected to support an interface for describing the interface. So they're self-describing. There is a heavy emphasis on notifications and events. So much so that frequently the return you get from a function call is not the real return and you're supposed to expect a notification later that whatever you asked for has finished. Very asynchronous. And the format of messages is a self-describing binary format designed to support a reasonable set of datatypes and user-defined compositions (aka structs). There is a reasonably heavy emphasis on data. Notifications are all about getting the right data to the right thing so it can do whatever it needs to do with it. Very few imperative 'you must do X in such and such a way or I will be very upset' sort of messages are passed.
D-BUS is RPCish, but many of the things I really dislike about RPC are either non-issues in D-BUS' environment, things D-BUS handles better than most RPC systems or both.
Thrift is not nearly so well designed. The main positive thing it has is a nice language agnostic method of describing a data structure in a way that allows for clever upgrades of that data structure later without breaking old servers or clients.
Thrift is not inherently self-describing. There isn't even a standard for asking an object implementing Thrift to send you its IDML, whereas D-BUS actively encourages objects to implement a standard interface for this.
Thrift has the concept of async methods that return as soon as they've made it to the transport. But the methods are still very function-call like, and they encourage thinking of imperative 'do this, change your state in this way' sort of messages. I asked on the Thrift channel about an 'idempotent' method modifier for a method that could be implemented via HTTP GET and people were puzzled as to why I'd even want such a thing. The idea of using RPC to implement REST were met with general puzzlement.
Lastly there is no standard way of naming objects in Thrift. And the HTTP transport that comes by default just assumes it will be sending data via POST requests to
http://something:port/, not much of a standard for naming the thing you're talking to at all.
So, Thrift as it stands is very poor for implementing random publicly accessible services.
I've been thinking that having web pages for interacting with data that will return a Thrift encoding of the data if passed an
Accept header might be interesting. They could even accept
application/x-thrift data in HTTP
PUT requests. This would allow you to use URLs to name objects and a fairly efficient, easily parsed protocol encoding for sending the data needed to manipulate them.