Re: CORBA performance - why CORBA

[Michael Meeks <michael peabody ximian com>]

Hi Havoc,

On 3 Dec 2001, Havoc Pennington wrote:
>   a) the current approach of having to subclass a new IDL interface to
>      extend the "protocol" is really cumbersome; being able to just
>      add a new kind of message would be simpler.

        cumbersome ? it is quite an explicit contract - and documented;
you prefer to add string APIs willy nilly without an explicit contract - a
string is still an api, blah blah blah :-)

>   b) to avoid round trips; I'd like for example a "set key to value"
>      operation to be oneway (yeah I could just put oneway
>      on all existing methods, for this).

        Quite; oneway is great.

>   c) to avoid re-entering the main loop on gconf calls; even
>      for round trips, ideally.

        This is only ever an issue for applications that implement CORBA
servers - it doesn't affect standard user code. If you implement a CORBA
server - you get re-enterancy - c'est la vie - it's not as if GConf is
going to be a significant extra cause of re-enteracy cf.
Bonobo_Unknown_ref / unref eg. - unless that is gconfd has a somewhat high
latency.

>   d) to send only the data that's interesting; right now I have
>      several different "variants" of each method, that send
>      different args or retrieve different data subsets;
>      I'm still missing some I'd like to have. A text-type
>      protocol lets you have "optional named arguments,"
>      essentially, as in Python

        Well - sure but with a C binding around it - as you have, that's
no issue; surely you can send default values for these arguments ? sure -
for scripting bindings this might be a problem; but then the GConf IDL is
not for public consumption ?

        But you have a point - there are no default arguments in CORBA IDL
- but then there arn't in C either.

> I just think it'd end up a lot cleaner and simpler to deal with.

        I think it would perhaps be more extensible, but a string is an
API - and in this case it sounds supremely undocumented - that is unless
you're going to use SOAP or somesuch.

        One of the beautiful things about the ORB ( apart from it dealing
with the non blocking socket mess for you ) is that it stops people
cooking up new and nasty, undocumented string protocols :-)

> I'm not planning to do anything like this in the near future, it's
> more of a "someday" thing, like adding vector graphics to GTK.

        I look forward to the vector graphics :-)

        Regards,

                Michael.

-- 
 mmeeks gnu org  <><, Pseudo Engineer, itinerant idiot