Linked by Eugenia Loli on Tue 14th Feb 2006 19:06 UTC
Original OSNews Interviews 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.
Thread beginning with comment 95522
To read all comments associated with this story, please click here.
I'm diggin in at the site
by bryanv on Tue 14th Feb 2006 19:22 UTC
bryanv
Member since:
2005-08-26

And I'm finding it very hard to concentrate on my actual "work" that I have in front of me to do at my job.

Holy crap, this is _fantastic_. The Binder shell -- it looks like it's almost BeanShell (http://www.beanshell.org) for system services, and system objects. OH MY GOSH! THIS IS SOOOO FREAKIN' COOL!

Reply Score: 3

RE: I'm diggin in at the site
by dcibils on Tue 14th Feb 2006 20:35 in reply to "I'm diggin in at the site"
dcibils Member since:
2005-12-28

I feel the same and finding it very hard to finish my assigned tasks here at work!

I wish I have some Linux distro right here to test this beauty on!

I once heard a msft MVP guy saying that COM (component object model) was THE big advantage over Linux/Unix but. I know there was always CORBA, but I don't know why this guy said that (from a tecnhical pov), it just kept in my mind.

Reply Parent Score: 1

hackbod Member since:
2006-02-15

Hi! Thanks for all of your nice comments; I thought I'd batch up my replies in one post.

"OH MY GOSH! THIS IS SOOOO FREAKIN' COOL!"

Thanks, I can't tell you how nice it was to see that as the first public response anywhere. ;)

"I once heard a msft MVP guy saying that COM (component object model) was THE big advantage over Linux/Unix but. I know there was always CORBA, but I don't know why this guy said that (from a tecnhical pov), it just kept in my mind."

That statement seems a little over-the-top. ;) COM used to be Microsoft's religion, but now they've moved on and .NET is their new religion.

I do think there are some advantages that Microsoft has with COM on Windows, but those are mostly due to their position as a closed-source company: that allows them to create a platform with a much more consistent and cohesive API, and they got a lot of mileage out of that with COM.

For example, a long time I worked at a data visualization software company. With COM, we could write our data visualization components as COM objects, which could then be used all over the place: as big rich controls in VB applications, embedded in spreadsheets, etc. That's pretty cool, and because it is based on a strong platform API it allows those components to be reused (with no additional work) in a wide variety of places.

"But I found COM to be a clunky thing."

I agree! Having had to work with COM, that was not an experience we wanted to replicate in OpenBinder. One thing we spent a lot of time on was taking advantage of C++ to greatly simplify the details of programming with it. For example, reference counting on Binder objects is designed so they can be managed completely with a smart pointer class included in the system -- thus you never have to think about reference counts yourself.

Have a look at http://www.openbinder.org/docs/html/BinderRecipes.html to see what real-world Binder C++ code looks like.

"From what I can see, COM was created to give C and C++ (and others) a way to dynamically bind to objects. If you use a language like Objective-C (there are lots of others) you don't have this problem as binding to objects dynamically is their bread and butter."

It is true that these kinds of component models add higher-level facilities to C/C++ that you can get with other languages. However, there are other just as important features, such as:

* Automatic binding between languages, so that different programming languages can automatically interoperate with each other. (Our data visualization components, written in C++, being used in VisualBasic is a typical COM example.)

* Managing cross-process communication. That is, allowing objects to interact with each other across process boundaries without having to do anything special or write communication code.

In other words, there is no competition between something like Binder and a specific programming language -- in fact one of the big points of such a system is to give you more freedom in selecting the language that is most appropriate for the task at hand.

"Oohh, lots of nice references to libbe2 and support kits, etc"

Yeah, this was started at Be and a very very early version of it was in "libbe2" that was part of the leaked distribution.

"It would be nice to have something as clean and straight forward as the bebook for OBinder."

I don't know that we'll get anything much better than is what there now, unless someone wants to help out.

All of the documentation can be found at http://www.openbinder.org/docs/html/index.html. The "Programming Guide" is general documentation, and reference material on the classes can be found for example at http://www.openbinder.org/docs/html/annotated.html.

For an open source project, I think we are doing pretty good on documentation! ;)

"Anyone who thinks that binder is a novel approach for adding OO to OSes isn't familiar with Clouds or the other spectacular past failures of attempts to bring OO to OS."

Could you add to this? What is it about OpenBinder that has failed in the past? I'm not all that familiar with Clouds, but I really don't see much similarity between them: we are designed to sit on top of a traditional OS kernel (not a special microkernel), our objects do not have their own address space or anything special like that, we are not trying to do a system that is distributed across multiple computers, we are not extending C++ to support our programming model, etc.

In other words, a very basic difference is that OpenBinder is designed to leverage, and interoperate with, our current operating systems, not to replace them. As such, it can be used in part or whole for implementing certain things where it makes sense; there is no need to replace major existing pieces (such as the kernel) for it to be useful.

If you are going to compare OpenBinder to anything, I think it is by far most like COM. And I would find it hard to argue that COM wasn't a success. The most significant different we have from COM is that we are trying to apply COM-like features to system-level design.

As far as I am concerned, the Binder design has already proven itself to be a success (meaning "proven to be working") in that we have been able to implement a wide variety of real working system services with it: from a multi-process display server, to a multimedia framework, to smaller things like a shared memory manager. It has evolved from the beginning as a standard infrastructure for solving the kinds of problems that are encountered when implementing such system services.

Reply Parent Score: 5