I thought you know all too well what happens when you give a single dev a few month of time to redesign a whole system API. This is how the BeOS media kit was done.
Designing core APIs like this need a lot of time surveying existing applications, their use for the API, the problems they hit, and then thinking about solutions. I think this is much better done in a group discussion than by a single developer working alone. I don’t think anyone can have a good view of everything: the implementation details that make a solution workable or not, the use in native applications (both simple and complex ones), in ported applications, either using a ported toolkit (Qt) or using native options (WebKit / WebPositive), with realtime needs (media stuff), etc. No one can pretend to have experience and vision of all these things at once.
So what we need is get everyone ideas and try to build a common vision of where we should go with things. Real life meetings are an ideal place to do that, but it may not be convenient with our team, so we will have to fallback to some less practical way of doing this.
On to OpenBinder, and before even discussing the details of how to implement it…
There are two major annoyances I identified in the BeAPI while working on applications.
One is the lack of a signal-slot like system as in Qt. In Haiku, you have to do a lot of subclassing to handle incoming messages, because there is no way to plug things together “from the outside” as you would do in Qt by connecting signals and slots. A little-used API actually allows this: StartWatching() / SendNotices(). I think we should rework most of our objects (BControl, possibly network stuff, etc) to use that instead (or in addition to) sending “well known messages” to a single target. Note that I don’t get into implementation details here, maybe this is orders of magnitude slower than usual BMessages currently.
The second problem is the pain of writing the MessageReceived function everywhere and handling messages. This is where the Binder comes in. The idea is to implement the usual RPC (CORBA and these things were hyped back then) and allow direct procedure calls, even between process, hiding the low-level construct of message passing. This fixes the second part of what signal/slots achieve in Qt: no need to think in terms of message passing anymore, we really get to think into events and callbacks triggered by them.
The main advantage over Qt is that Binder also bridges between applications, something that is key to the BeAPI. Ideally we would go further and bridge accross machines, allowing this to work transparently over the network as well. And we can already bridge time, by serializing a message to disk and reopening it in the future, it seems useful to keep that possible as well.
Now, we can evaluate our options. Is Binder still the best answer for it, or are we still blinded by Be marketing and hype around it? What did other people achieve in the last 20 years? Were there lessons learned about Binder after its use in Android? How does Qt do these days? What about Plan 9 (for the network transparency bit, at least)?