Re: Scripting in Gnome

[Jody Goldberg <jody gnome org>]

On Thu, Feb 05, 2004 at 05:24:48PM +0000, jamie wrote:
> On Thu, 2004-02-05 at 17:01, Sean Middleditch wrote:
> > On Thu, 2004-02-05 at 11:51, jamie wrote:
> > > On Thu, 2004-02-05 at 16:16, Sean Middleditch wrote:
> > > 
> > > > 
> > > > What makes you think D-Bus is any faster than CORBA?  We already have
> > > > one backend that does everything we need it to already, so why do we
> > > > need alternatives?  What advantages do we get for all that extra
> > > > development time and complexity?  What about the fact that apps would
> > > > then no longer inter-operate because some would use backend A and others
> > > > use backend B?
> > > > 
> > > The fact that slow bloated KDE thought the Corba implementation in Gnome
> > > was slow and heavy on memory usage and hence decided not to use it
> > > speaks for itself.
> > 
> > That is a ridiculous claim.  That's how slow/bloated software gets
> > written.  Instead of saying, "KDE doesn't liek Corba," try showing some
> > benchmarks to prove your claims.  If we're just going off what KDE does,
> > we have a lot more changes to make to GNOME than what IPC mechanism we
> > use...
> 
> Bonobo is not as popular as COM is on MS platforms - I wonder why that
> is? 

Bonobo on its own was a nice.  IMO the problem was that CORBA is a
pain in the butt on many levels.  Toss in bonobo-activation and
your developers have a swath of irritation ahead of them.

    - mapping to/from corba types into native types is a pain that
      is replicated at each end and error prone.  Have a look at the
      corba C and C++ bindings.
    - idl pretends to provide an interface, but quickly gets bogged
      down when dealing with reentrancy (A calls B calls back to A)
    - activation is never as clear as you'd like.  Are you launching
      a factory per cpu/display/user/client/instance ?

In the end most idl apis I've seen tend to boild down to
    interface foo {
	void apply (inout string xml_gunk);
    };
which ends up causing its own set of problems.

> Also Orbit2 admits its around 20% slower than orbit1 in its own
> benchmarks.

Who cares about 20% ?  Orbit2 is far more compliant and stable than
Orbit1.  We're talking about scripting here.  Orders of magnitude
are important, a few percent are not.

I'd lean toward something like swig to generate interface code.