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.
- "OpenBinder, Page 1/2"
- "OpenBinder, Page 2/2"