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.
Order by: Score:
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 UTC 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 Score: 1

RE[2]: I'm diggin in at the site
by hackbod on Wed 15th Feb 2006 08:17 UTC in reply to "RE: I'm diggin in at the site"
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 Score: 5

Maybe it's just me...
by thavith_osn on Tue 14th Feb 2006 20:50 UTC
thavith_osn
Member since:
2005-07-11

but I found COM to be a clunky thing. I had to beat my head against a wall for over a year and a half dealing with it. It's OK if you are doing simple stuff, but anything that involves events coming back from COM for instance gets a little more interesting.

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. Everything feels a lot more natural.

My advice (esp. if you are using Linux) would be to check out a language that natively does this first.

Reply Score: 1

Binder
by YNOP on Tue 14th Feb 2006 22:07 UTC
YNOP
Member since:
2005-07-02

oohh, lots of nice references to libbe2 and support kits, etc

nice package. glad to see lots of this code "make it out". muscle did a good job of bringing some of that be-way out to a cross platform technology, however its nice to see allot more beeing released here.

if i can get this running on BeOS and OSX i might just find my way "back" home.


one small point. where is the BeBook for this code. I see some docs, and they look like they came from the same family of documentation systems that generated the old bebook (i know the code commenting style is similar)

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

oh well. its all super kewl though, thanks for the release

Reply Score: 1

red and blue
by JrezIN on Tue 14th Feb 2006 23:42 UTC
JrezIN
Member since:
2005-06-29

It's nice to see some red and blue back...
Nice logo! ;]

Reply Score: 2

Those who do not learn from history
by Cloudy on Wed 15th Feb 2006 03:40 UTC
Cloudy
Member since:
2006-02-15

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.

Reply Score: 1

Alternatives?
by obi_oni on Wed 15th Feb 2006 13:20 UTC
obi_oni
Member since:
2006-02-15

While this seems interesting, I would've liked to see the (non-)overlap with existing similar alternatives explained - or, "why/when should anyone work with OpenBinder, as opposed to these:"

- ZeroC's ICE
- Mozilla's XPCOM
- simple IPC's like D-BUS
- a common runtime like .NET/Mono

Another thing I was wondering about is the choice of the MPL (1.1?) as a license. Even if I wouldn't always license my code under the GPL, GPL compatibility is important imho.

Reply Score: 1

Looks good
by sean batten on Wed 15th Feb 2006 13:43 UTC
sean batten
Member since:
2005-07-06

I like the look of this. It's how COM would have ended up if C++ had been more widespread when it was introduced.

However, it's a pity that they're not using exceptions as their error handling mechanism. It mentions that this is because the ARM compiler doesn't support them. Still, they are trying to make an totally OO component framework and I think that it's a mistake....

Reply Score: 1

RE: Looks good
by eamoon on Wed 15th Feb 2006 22:09 UTC in reply to "Looks good"
eamoon Member since:
2006-02-15

Exceptions would be nice if it were possible to implement them without hideous run-time overhead. Checking return values isn't really so hard, though.

Why is making a component framework "totally OO" a mistake? How do you even define "totally OO"?

Reply Score: 1

RE[2]: Looks good
by sean batten on Thu 16th Feb 2006 16:45 UTC in reply to "RE: Looks good"
sean batten Member since:
2005-07-06

I meant that I think it's a mistake not to implement exceptions in a framework that is aiming to be "totally OO"

Sorry for the confusion

Reply Score: 1

props
by theGrump on Wed 15th Feb 2006 18:04 UTC
theGrump
Member since:
2005-11-11

who knows where this will go, but at least its some new thinking

Reply Score: 1