Re: DBus IDL (Was Re: GLib plans for the next cycle)

["Brian J. Tarricone" <bjt23 cornell edu>]

On Tue, 03 Mar 2009 10:55:33 +0100 Alexander Larsson wrote:

> On Mon, 2009-03-02 at 22:26 +0000, Rob Taylor wrote:
> > Brian J. Tarricone wrote:
> > > Whether or not the object is local (in-process) or not is
> > > irrelevant. Whether or not the method call is sync or async is
> > > also irrelevant. It's a method call, pure and simple.  DBus
> > > itself even calls them method calls.  All you're doing by
> > > avoiding that in the IDL is making us learn and remember yet
> > > another confusing and incompatible syntax.
> > 
> > Wow. No.
> > 
> > That was the main insanity of CORBA. Hiding that something is IPC
> > results in you thinking things are working one way when in fact
> > they're working completely differently and subject to a load of
> > unexpected failure modes.
> > 
> > Other things to consider here is that hiding IPC can also result in
> > hugely inefficient IPC because you end up designing a pretty API
> > rather than efficient IPC.
> > 
> > I could rant at length here about the various benefits of CORBA vs
> > message bus. But suffice to say hiding that there's a message bus
> > means you end up with CORBA again and all the attendant problems.
> 
> I very very much agree. And I had to fight these CORBA problems for
> many years maintaining a bonobo based application. Please learn from
> history and don't fuck up our platform again.
> 
> This should be required reading for everyone that ever touches IPC:
> http://research.sun.com/techrep/1994/abstract-29.html

Ok, I'm convinced.  Sorry for the noise.  (That's an excellent read:
short and clear, but still very thorough.)

However, I'm still not convinced that the IDL for this should be some
weird C-like syntax that makes everything look like messages rather
than method calls.  In fact, that paper you reference even notes that
interfaces can still be defined using a 'normal' IDL, and then the
parser would generate implementation based on whether or not the access
model is intended to be local or remote, tailored for that access model.

And if we still absolutely must use a weird message-like syntax, then
why use a C-like syntax at all?  Seems like it would be less confusing
just to invent something new, or reuse something that already exists as
to describe message-passing interfaces.

	-brian