Why Not Use CORBA For Script Language Bindings?

tjansen asks: "While looking into the GTK library, I notice that there are a large number of GTK bindings for scripting languages: Perl, Python, JavaScript, Guile...almost every language has its own GTK binding with its own syntax that all have to be maintained (and documented) separately. The same problem exists for all C or C++ based libraries, writing wrappers for scripting languages is just a lot of work. On Windows systems COM is used to make libraries and components accessible to scripting languages. Even if the COM interface does not fit very well to a particular language, for example because they don't use the language's naming convention, they give even obscure languages a great amount of libraries with almost no work other than writing ActiveScripting bindings for the language. Why maintain separate bindings when the community could use something like CORBA for the same thing? I think the idea is too obvious and something like this should be very useful for language interoperability in general. Is anyone working on such a project?"

"Now that the free software world more or less standardized on CORBA I wonder whether anyone already had the idea to use CORBA (or at least its object model and IDL) not only for inter-process communication, but also in-process to access libraries. The idea is simple: someone writes the IDL specification and a set of skeletons that wrap the C function calls into IDL methods. Instead of producing an executable server one would create a shared library with some special symbols/functions that describe the IDL interface(s) that it implements. The script interpreter could then load the library at runtime, discover the library's interfaces and provide them to the script. Alternatively, an IDL compiler could be written that creates stubs that access the interface."

Re:CORBA Doesn't Support "in-process" Interfaces

[Anonymous Coward]

That's what standard interfaces like the Basic and Portable Object Adaptors and CORBAservices are for--so every application and component will link with any conforming ORB the user wants to use. How could a spec mandate an ABI (which will almost always be something slow like vtbls) and accomodate negotiation of the best supported ABI for that object interface?

Re:I like Corba

[tjansen]

Yes, they use Corba, but for inter-process communication. For example Corba is used for communication between the gnome panel and the applets - they are different programs. But my idea is to use for accessing a library from program, preferably a scripting language that cannot access regular c/c++ libraries.

Good question.

[booch]

I've been wondering the same thing for quite a while now, especially since GTK+ is object-oriented and written in a non-OO language. It seems like the ideal way to use an existing OO framework of sorts and get free easy language bindings. Right now they've got some custom Lisp-like description language that several languages use to create bindings, but the description has to be modified somewhat for each binding.

The only answer I can come up with is that CORBA is too big and would slow things down too much. But Orbit is supposed to be light-weight, so I'd like to see them put their money where their mouth is and implement CORBA bindings.

Re:CORBA Doesn't Support "in-process" Interfaces

[Kristopher Johnson]

Not true. When you compile a CORBA application, the resulting object modules will only be linkable with a single ORB's libraries. BOA, POA, and CORBAservices don't help with this. BTW, what's faster than vtables? -- Kris

CORBA Doesn't Support "in-process" Interfaces

[Kristopher Johnson]

COM can be used for scripting languages and cross-language development because it is a binary standard. COM components can be loaded into a process and used by clients within a process, because Microsoft has defined what the low-level bindings are.

CORBA, on the other hand, strives to be independent of languages, operating systems, and other platform-specific issues. So the OMG has stayed away from low-level binary bindings.

There are good reasons for CORBA's focus on platform independence, but the downside is that there is no standard way to load components from a shared library and access them. Some ORB products do provide this capability, but they are not interoperable. (For example, if you build a DLL that uses MICO, you probably can't use it from an application written that uses Orbit, omniORB or TAO.)

Check out the comp.object.corba newsgroup archives for more information about this. This subject comes up a lot--someone asks "Why can't CORBA do what COM does", and someone replies "COM sucks. Microsoft sucks. Why on earth would you want to do what they do?"

I like Corba

[danpbrowning]

I like corba. I think it's a great idea, but I thought Gnome (or was it KDE?) was already using Corba. (Maybe they are using corba for something else and I'm confused.). Anyway

Re:I like Corba

[King of the World]

Gnome are introducing a superset of CORBA dubbed 'Bonobo' (being a joke on the CORBA component architecture - that fits anywhere - like a bisexual Bonobo monkey).

Berlin [sourceforge.net] is built around CORBA too.