Langauge Independent Component Models

Posted 25 Nov 2005 at 11:12 UTC by zbowling Share This

A lot varities of component models. Mozilla's XPCOM, Gnome's Bonobo, Win32's COM/COM+ abd OLE, Open Office's UDK/UNO, and so many others. Which is worthy of attention?

One of the things I'm working towards in my time working on Mono is offering a possible cross platform alternative for COM's intergration into .NET. Since there are so many choices, its hard to know the native benifits and caviots of each. I'm trying not to limit hte Mono implimentation to any one specific model, so I'm makring sure I'm nearly an expert at them all before any specific apis are set in stone. Its a difficult but I've learned some interesting things.

Alot of these systems have a similar basic concept. They usually provide a reflection system to discover interfaces at runtime, and usually provide a method for binding dynamicly (late binding) and binding at compile (early binding). They also usually have some sort of method of registrating new components. Usually, these systems are designed in this manor because they don't want to limit themselves to a single langauge, or fear versioning and naming conflicts that may be solved in a higher level system then what the langauge provides out of the box. This means that Mono should be able to intergate, and not specificly tie it to one platform which would break one of the main goals of Mono.

The options are pretty open.

XPCOM - Mozilla and Firefox is based entirely on this model. Its very very similar to Microsoft's COM but more desktop/UI orientend, although, hardly limited to to that. Bindings for Python, Java, Perl, Javascript, and C++. Its cross platform and after intergrating, all of Mozilla's components are accessable such as XUL and Gecko.

COM - Limited to only Windows and it has changed over the years. ActiveX, OLE, DCOM, and COM+. While not being my personal favorite, it does have more components then any other framework.

Bonobo - Very similar to Microsoft's orginial OLE. Bonobo is based on Orbit/CORBA. Although Bonobo still is used, I really haven't heard of any recent development with it.

UNO/UDK - OpenOffice's model. Although I haven't looked into it much myself yet, I heard its simple to integrate into.

I'm going to make it work with XPCOM first and then move onto moving the UNO work already done into this new model. So much work, so little time.

A few notes..., posted 28 Nov 2005 at 08:40 UTC by pphaneuf » (Journeyer)

Do not confuse ActiveX/OLE (which are very close relatives), with COM/DCOM and COM+. ActiveX/OLE are frameworks built on top of COM. Bonobo is mostly a relative of ActiveX, replacing COM with CORBA, but had to include some parts of COM to cover some differences.

You are correct in picking XPCOM as a first "victim", I believe, as it is very similar to COM, which already has machinery to support it in MS .NET. UNO would probably make a good second one, but I am not as familiar with it.

Try to focus on the interfaces themselves rather than the object they represent. Avoid the IDispatch reflection style as much as you can, as it loses interface identity.

You mention specifics of C++ compilers on your blog. I suppose you mean symbol mangling. Interpreting the symbol mangling is a path to be avoided as much as possible. COM, as well as XPCOM (and XPLC, and most likely UNO as well), has a fixed ABI based on the layout of the vtables, avoiding depending on the specifics of C++ compilers).

I am rather interested in the "emerging ideas for a new technique of mixing GC systems", if you could provide a pointer, I would be highly interested. At the moment, the only GC strategy that seems (to me) portable across GC systems is reference counting. And yes, it can cause circular reference cycles, if they go across more than one GC domain, hence my interest in anything better.

Interface Description Language, posted 5 Dec 2005 at 23:10 UTC by aminorex » (Journeyer)

IDL compilers are a great tool for abstracting out the details of component object protocols. Take one off the shelf and tuck in a back-end for whatever component systems you want to support.

XPCOM implementation without ties to Mozilla?, posted 11 Dec 2005 at 06:24 UTC by atai » (Journeyer)

Is it possible to use XPCOM without using Mozilla's code base? For example, would it be possibe to create a C-based implementation for use with GNOME, without depending on Mozilla code but interoperating with Mozilla components?

Re: XPCOM implementation without ties to Mozilla?, posted 12 Dec 2005 at 08:13 UTC by pphaneuf » (Journeyer)

atai: it is indeed possible to use XPCOM outside of Mozilla. Or if you mean without using Mozilla's codebase at all, this would also be possible, but much more difficult, as many components use common components bundled with XPCOM itself, these would have to be reimplemented.

layer upon layer, posted 12 Dec 2005 at 11:29 UTC by lkcl » (Master)

it is interesting to note that COM is available in .NET.

that takes the software layering dependence, created by microsoft, to a new extreme.

remember: freedce is the open group's reference implementation dce 1.1, autoconf'd and ported to linux (including amd64). msrpc is derived from exactly the same codebase.

then, the specifications are available for DCOM (and therefore also for COM) on the internet, without restriction or limitation, at

but first, you must make freedce utilise NT-style authentication (which i have done, if you don't mind NT 3.51 / 4.0 style domain authentication).

remember also that the wine team is creating a non-interoperable (non-interoperable with freedce) reimplementation of freedce and then DCOM on top of that (i had to point them in the direction of the comsource documentation, would you believe it).

remember _also_ that the samba team is creating a non-interoperable (non-interoperable with freedce _and_ with the wine team's implementations!) reimplementation of freedce which is to be MSRPC-wire-compatible and MSRPC-idl-compatible but nothing else.

so as a free software community we are a complete fuck-up that has microsoft laughing all the way to the bank.

Dont forget about KDE and Java, posted 17 Dec 2005 at 23:40 UTC by eckes » (Master)

I think the Integration of KParts/DCOM is missing in the above list.

And I dont know if Java Integration is on the same level, perhaps thats more a question of remoting? (RMI or IIOP)


typo.., posted 17 Dec 2005 at 23:42 UTC by eckes » (Master)

Sorry typo: DCOP not DCOM as the protocol underneath KDE components.

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!

Share this page