Introduction to OpenBinder and Interview with Dianne Hackborn

OpenBinder is the core technology that ex-Be engineers started at Be, Inc. as the “next generation BeOS”, finished implementing at PalmSource as one of the key foundations of the Cobalt system, and is now being open-sourced running for Linux. Dianne Hackborn, a legendary engineer throughout the BeOS history and later a key engineer in the creation of PalmOS Cobalt, is describing OpenBinder below and then a mini-interview follows.

OpenBinder is a new approach to operating system design, in the same vein as a lot of other attempts at introducing a modern object oriented approach to operating system design. Usually, however, when this is done it is at the kernel level: creating an “object oriented kernel,” which is significantly different than our current modern kernels. The Binder, in contrast, provides a rich object-oriented operating system environment that is designed to be hosted by today’s traditional kernels.

An illustration of this can be see here where we show how you work with processes in the Binder, treating them as just another kind of Binder object. There are similar OO representations of shared memory, byte streams, files, etc. These all sit on top of traditional operating system services, for example when you do “new_process” the underlying OS calls (fork() and exec()) are used to create the process; however, the way the Binder presents these things to you provides a radically different, and hopefully richer, programming model. As an example, OpenBinder includes a traditional command line shell (called Binder Shell), that illustrates how using the Binder to implement such a core system service provides a much more powerful environment. At a high level, the Binder Shell can be compared to Microsoft’s new shell.

The Binder is technology that was started at Be, as the foundation of a new set of graphics, user interface, and multimedia frameworks, for a next-generation operating system. When Palm acquired Be, all of this technology was ported to Palm’s microkernel and used to create Cobalt. With the switch to Linux, it was then all ported to Linux, and OpenBinder is the result of work we did to get some of that technology open-sourced so that is available to others. (Unfortunately at this point the graphics, user interface, and multimedia frameworks, which were used to drive the development and design of the Binder, are not being open-sourced.)

Over the approx. 5 years of its life, the Binder has run on BeOS, Windows, the Cobalt kernel, and now Linux. The current OpenBinder
distribution only runs under Linux, however it would not be hard to get it working again on the other kernels, and we have enough experience with it to be pretty confident that porting to other platforms should not be too hard. Also, for most of its life, the hardware target for the Binder (and everything built on top of it) was a 200 MHz ARM CPU, so it is relatively lightweight and already includes extensive optimization of the key code paths in the system.

1. Could you give us a real application example of Binder so our readers understand it better?

OpenBinder itself is not interesting to end users, but rather is a set of tools that other developers can use to implement rich operating system services and applications. An application-level example requires some higher-level piece of software implemented on top of it. There have been a number of such things implemented with the Binder, including a distributed display server and user-interface framework, componentized application model (like a document component model such as OpenDoc, but for putting together applications instead of documents), and a rich node-based multimedia framework. Unfortunately, these are not a part of OpenBinder at this point.

One example that is included with OpenBinder is called the Binder Shell. This implements a POSIX compatible shell (like bash and the Korn shell on Unix). It sits on top of the Binder framework, however, giving a much richer environment than you would get from a shell designed for traditional operating system services.

This page has a lot of detail on the shell, but here are some quick examples of the kinds of things it can do:

The shell sits on top of the Binder runtime, so all of its variables and data are dynamically typed via the Binder and it has access to the full OpenBinder component model. Because of this, the shell can easily instantiate any OpenBinder component and interact with it. As an example, here are some commands that instantiate an example component included with OpenBinder and call a method on it:

/$ s=$[new org.openbinder.samples.Service]
Result: sptr(0x80a0194 13SampleService)

/$ invoke $s Test
Result: int32_t(12 or 0xc)

In fact, the Binder Shell is just another VM for OpenBinder that lets you write Binder code in its particular language. When you write a script in the shell you are actually creating a Binder object, allowing you to do interesting things like write a function in the shell that gets invoked by another object in the system. For example, you can use standard POSIX shell syntax to write this function:

/$ function handleEntryCreated() {
	echo "Created: parent=" $1
	echo "Created: name=" $2
	echo "Created: entry=" $3
}

And then use the OpenBinder facilities to link yourself to the “/settings” directory (the link command takes advantage of a standard facility for connecting the output of one object to the input of another):

/$ n=$[inspect /settings org.openbinder.support.INode]
Result: sptr(0x8091dc4 8BCatalog)

/$ link $n $SELF @{EntryCreated->handleEntryCreated}

And now if someone changes the contents of that directory:

/$ echo >/settings/test "This is a test"

Your shell function will be invoked, resulting in the output:

Created: parent= SValue(sptr(0xb69063f4 8BCatalog))
Created: name= test
Created: entry= SValue(sptr(0x8081254 N18SDatumGeneratorInt12IndexedDatumE))

For a full-fledged example of writing a Binder component in shell, have a look here for the same test component we saw above but implemented entirely with BinderShell. (The component we used previously was implemented in C++ and can be found here).

Some examples of coding in C++ with OpenBinder can be seen here and OpenBinder includes a variety of high-level tools that make development much easier. For example, there is a built-in thread pool and a class called SHandler for accessing it that makes it very easy to do a number of common threading tasks (see here), a light-weight locking class with a sophisticated tool for detecting uses of it that can lead to deadlocks, reference counted objects with their own debugging tools for detecting and correcting leaked references (see here, and the obligatory string class, container classes, and other tools.

Of course, working with multiple processes is where you get the most out of OpenBinder, because like other distributed systems it takes care of all of the details of communicating between processes for you. For example, consider the first shell example we showed above of instantiating a sample component and then calling it. Here is C++ code that does the same thing, but runs the component in its own process:

sptr process = Context().NewProcess(
    SString("my empty process"));

sptr obj = Context().RemoteNew(
    SValue::String("org.openbinder.samples.Service"), process);

sptr srv = interface_cast(obj);
int32_t res = srv->Test();

With these few line of code, you have started a new process, found some code (that can be implemented in any language) by name and loaded it into the process, and performed an IPC from your process to execute that code and get a result back.

In addition, the object and its code will remain loaded for you only as long as you hold references on the object, and the process itself will be kept around only as long as it is needed, going away once all reference on it and its objects have been removed. In other words, if you were to put that code as-is into a function, it would not only do all of the starting and loading and calling, but correctly clean up everything for you as well when the function returns.

2. How is OpenBinder different than Corba in particular? What its advantages are over it?

OpenBinder is actually most like COM, and here you can find some discussion about the differences between them. A couple key points from there:

* OpenBinder targets C++ as a base-line language, allowing for a much simpler syntax; hopefully the previous example demonstrates this.
* OpenBinder is built on top of a scripting protocol, instead of that being tacked on to the side, allowing any scripting language (Python, Perl, Binder Shell, etc) to easily interact with every other component written with OpenBinder.

More significantly, OpenBinder was really designed as an operating system component framework. That is, it was designed to help in implementing system services such as display servers (like X), application models, the shell, multimedia frameworks, etc. This is one of the things that COM can also be used for — and is by and large outside the scope of CORBA and ICE-E. However, for whatever reason (complexity, overhead when going across processes) it doesn’t seem like COM has been able to fully address that space, and we are seeing for example Microsoft moving away from it and toward .Net.

Consider, for example, one of the key things that has been implemented with the Binder: a distributed user-interface framework. That is, a system like X Windows, except where every window (top-level, layout manager, control) is a Binder object, creating a true distributed system from the display root down to each button that can be spread across processes as desired. Trying to implement this kind of thing stresses a component system (like the Binder, COM, CORBA, ICE-E) in ways that most of them have not been designed to handle, simply because they are more interested in cross-network communication where very different performance characteristics are in effect.

With the Binder, however, we were able to have a production-quality implementation of such a system… whose target device was a 200MHz PXA250 (Intel ARM) CPU, fully multi-process with the display server and applications running in separate processes. And by implementing this with the Binder, we were able to have a unified architecture where the display server, window manager, and layout managers and controls inside of a window all sit on the same backbone — so that any piece of your window could itself serve as a full-fledged window manager for other parts of the system. This allowed, for example, an application UI to host a full browser session inside of itself, dynamically splitting itself across processes as needed and depending on the resources available.

The concept for the Binder is really at a lower level than how these other component systems tend to work. In fact, the Binder currently does not include support for communicating over a network. This is possible to do, but just hasn’t been a priority for our “system-level” focus so far.

3. Please explain to us the usability, UI implications for using a Binder-specific architecture on a phone or PDA.

OpenBinder is not a UI, it is just a component system for developing whatever operating system services you want, so it does not say anything explicitly about what a UI implemented with it would look like.

That said, much of its design was driven by the needs of the kinds of user interface features we wanted in the framework built on top of it. These include:

* Scalability — dynamically deciding how to distribute the user-interface across processes depending on the resources available;
* Stability — allowing an application to put parts of itself it may not trust (a web browser UI, video player, etc.) into a separate process without any visible difference seen by the user; and
* Flexibility — the normal component architecture advantages of dynamic replacement of UI elements (buttons, lists, etc), deep integration of multiple languages, etc. Pushing the component model up to the application level, this also includes the seamless incorporation of one application’s functionality into another, or extending the capabilities of an application by adding new user-interface components to the system.

Also, note that there is nothing about OpenBinder that makes it specifically for phones or PDAs. One of its design goals was to provide an infrastructure that can be used to create operating system services that can scale from embedded devices up to high performance desktop systems. The current OpenBinder build system is primarily oriented towards development on desktop Linux systems.

4. What kind of participation –if any– you would like to see from the Linux hackers on the Binder project?

We are currently putting together some ideas for initial projects to be done with OpenBinder, which anyone is welcome to be involved with, and welcome any suggestions from others. We also really hope that the current implementation will be useful for some people in their own projects, and have many active maintainers who will be around to help answer questions.

One kind of project that would be very good for people wanting to get their feet wet is implementing bindings to other scripting languages, such as Python, Perl, or Ruby. This is a great way to learn about the Binder architecture, and has immediate utility for many people.

5. Palmsource has initiated its own Linux phone standards a few months ago, but so have 2-3 more organizations. How do you see this
competition between different standards? Why can’t we all get along and have a single standard?

I no longer work for PalmSource (editor’s note: Dianne is now at Google), so can’t speak for them on this. Personally, I think what you are seeing is that the mobile phone industry is currently facing a number of big software challenges. There is a growing consensus on Linux being part of the solution for those problems, but the current desktop-orientied Linux world is not a complete solution, nor is it really clear what the correct solution is.

And anyway… isn’t multiple competing standards what open source is all about? 😉

6. And the million dollar question: is PalmOS-6-Cobalt-as-we-know-it a dead project?

Again, I can’t say anything for PalmSource, besides what they have already said: the future direction of PalmOS is Linux. One of the results of that is OpenBinder, which was a central part of the Cobalt architecture.