Questing regarding ORBit and D-BUS

[Michael Meeks]

Hi James,

On Fri, 2006-07-14 at 15:05 -0400, James Lampton wrote:
> I'm on a development project that is creating a suite of applications
> that need a lightweight, high-performance, IPC mechanism for command
> and control (for breaking a monolithic C process into smaller
> functional units for maintainability).

	Hokay; sounds like an interesting problem domain.

> We've implemented a prototype using ORBit2.  We're comfortable with
> the speed but there are quirks to it (as to be expected with any
> system).  In addition to breaking up our process, we would like to add
> the ability to work with different languages as well (currently Python
> and probably some Java).  When seeking help with the pyOrbit someone
> mentioned D-BUS.

	Right - seems reasonable; I took the liberty of CC'ing the D-Bus list -
I'm sure they'll be interested to give you a 2nd opinion from a
different perspective.

> Since you are listed as an author on both projects, I was wondering if
> you could recommend one over the other.  We like the multiple language
> bindings and documentation that D-BUS has, but we're concerned with
> its maturity (incorrectly perhaps?).  I assume the main customer for
> ORBit is the Bonobo system (which explains the lack of ORBit
> documentation while Bonobo documentation is readily available),
> whereas the D-BUS system appears to be filling a more generic role.

	So ;-) most users of a technology end up working on fixing the
technology themselves, since almost nothing does what it claims; on that
basis you'd have more fun working with the D-BUS guys I guess, ORBit2 is
very idly maintained - but then is far more mature.

> Can you lend any insight into PROs and CONs we may be missing at this points?

	Up to you really; depends if you care much about standardisation -
ORBit2 conforms to some subset of the OMG spec. and thus you can interop
with the std. JavaORB (as used for a11y), there are CORBA Python
bindings (as used eg. in the ORCA screen-reader), but AFAIR no extant
perl bindings.

	On the other hand - the CORBA bindings, while efficient are rather
loathed (at least for C users of glib types), D-BUS has the opportunity
of having really sweet bindings - since they have complete freedom,
unconstrained by existing specs. Unfortunately, [ IMHO ] the glib
binding is not at the level of sugar-sweetness I'd hope for (just now),
but it's being fixed (I believe).

	If you want type safety, and an IDL compiler, ORBit2 seems the best
choice as of now, but again, this is being fixed for D-BUS. If you want
complex threading handling, and stable and deployed libraries you can
link against [ on older systems ], then again, you should prolly use
ORBit2, D-BUS is only just frozen & will take a year or two to be widely
deployed in that state.

	Then again, if you don't want re-enterant request processing (and you
don't ;-) and you don't like threads, then you prolly should be using
D-BUS - which can expose the incoming request queue for traversal in a
pleasant fashion.

	If you want API extensibility [ and you do ], then you want the
(proposed) D-BUS method extension scheme (using the marshalled type data
not available in CORBA calls).

	If you want to represent large numbers of disparate, anonymous object
handles from a scripted language - D-BUS is a non-starter, the
introspection overhead will kill you - [ you'll have to engineer type
annotated references in yourself in some way ] ( this is AFAIR a
protocol-level problem that is as yet to be addressed ).

	Conversely - there are ~no live / motivated / extant ORBit2
maintainers / developers around, and for better/worse the
wave-of-the-future technology is D-BUS as of now.

	So there really is no right answer to the question ;-) like all
engineering decisions it depends what you want, when you want it etc.

	HTH,

		Michael.

-- 
 michael.meeks at novell.com  <><, Pseudo Engineer, itinerant idiot