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 (Score:1)
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 (Score:2)
Good question. (Score:2)
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 (Score:1)
CORBA Doesn't Support "in-process" Interfaces (Score:2)
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 (Score:1)
Re:I like Corba (Score:1)
Berlin [sourceforge.net] is built around CORBA too.