I hinted at this topic in my last entry and when giving my crazy thought of the day last week. It's another Friday, but judging from the comments to those blogs and my gut, I'm convinced now that an OSGi implementation for native development isn't really that crazy.
Everyone has heard of the Microsoft Component Object Model (COM). Even if you don't chances are you've used it. It's now getting long in the tooth but it was a critical technology that led to the success of the Windows platform starting with Windows 95. It was a great way to build up frameworks with plug-ins and to write components that used the services of other components, e.g. a Visual Basic script that ran inside Excel.
But of course, COM is very specific to the Windows platform mainly because of it's reliance on the Windows registry which provided the directory to find the COM classes and objects you need. It also had some weird tricks with threading models and some wacky things called thunks to help to help performance when we were running Windows 95 on our old i486 machines.
But it's been done and there's lots of things we can learn from that, and from the limitations of some of the others, like CORBA. Using C++ as the core technology is one thing we would need to avoid. Different compilers have different ABIs, like how virtual function tables are laid out. As much as we try to evolve, at the end of the day, C is still the best language for interoperability and almost every language provides a way to call C functions.
There was some discussion in the OSGi community around something called Universal OSGi lead by Peter Kriens who is also involved in Eclipse. If anyone knows the status of that I'd be happy to take a look. It shouldn't be too difficult to start with the OSGi APIs that make sense and start implementing a framework to support it.
Hopefully, whatever is chosen will do a better job than those other technologies. I'm using a couple of pieces of middleware built on top of TAO. Much of the time it just seems to be complexity building on top of complexity. Perhaps the mistakes pointed out in
ReplyDeleteThe Rise and Fall of CORBA will not be be repeated with this new effort.
I think the success of a new C++ module system where others have failed will depend on the tools that enable its use, and its ability to address cross-platform issues.
ReplyDeleteI'm thinking you'd want to store #include files (or an abstraction of them) in a "C++ bundle", in order to define imports & exports. I'd also want tools to easily convert existing libraries into modules -- for starters, something that could import autoconf-based projects, or a set of libraries and headers already installed in /usr/bin.
I'm wondering if SWIG (or something like it) could be used for defining the imports/exports across the language boundary. IDLs like SWIG should only be necessary when crossing this barrier, and maybe they can be automated to some degree?
Also, I wonder how C++ bundles should be stored? As JAR files? Standalone shared libraries with extra metadata inside? Or something else?
Here's another crazy idea: what do you think of using LLVM for this C++ module system?
ReplyDeleteLLVM has good compiler support, good performance, and a VM would remove architecture-dependent concerns.
How well you could get it to interface with native libraries would be a concern...
I never heard of LLVM. I'll have to take a deeper look.
ReplyDeletePart of the motivation for this, though, as mentioned in the title of this entry, is to support native development, i.e., no VMs. I'll reserve another blog entry for the VM versus no VM debate, but if you were thinking of using a VM, why wouldn't you just use Java.
I'm very confident that we can do this in C with C++ wrappers and it'll look pretty nice.
So if you could have COM without windows specific dependencies and cruft, would that be essentially what you want?
ReplyDeletePretty close, yes. But I also want the services and lifecycle management infrastructure from OSGi, which I guess would be the thing that replaces the Windows registry.
ReplyDeleteAs far as the interfaces to the services, yes, COM would be a good role model for that.
[nitpick] COM = Common Object Model, not Component
ReplyDeleteSpeaking of COM, it has many serious (design) flaws, specifically:
* metadata bloat (TLBs) stemming from (being limited to) single inheritance
* object incompatibility when interfaces are added / augmented (see previous)
* no structured exception handling; methods always return SUCCESS or fail, not actual values
* manual reference counting was a serious headache
XPCOM essentially has the same flaws.
I developed a binary object model that was cross-abi, lightening-fast, supported structured exception handling, multiple interfaces (inheritance), etc. about 10 years ago - even integrated it with Java (via JNI) such that it was 100% transparent to proggers. Difficult to generate interest because no one outside of certain development circles understands the concept of binary objects... :(
Great points Laurie. I was thinking more of adopting some of the concepts of COM where they make sense in the modern era.
ReplyDeleteI think you still need an IDL, maybe Java interfaces are sufficient. And do all calls across interfaces using C calling conventions to ensure cross language/cross compiler compatibility.
I'd love to spend some time on this to create a prototype to show what I'm thinking.