Re: CORBA performance.

[Havoc Pennington <hp redhat com>]

Mathieu Lacage <mathieu gnu org> writes:
> > For example, there is no reason GConf _can't_ be implemented with
> > CORBA - but really in the end the IDL _should_ have been something
> 
> Why "_should_" ? Would you mind explaining why ?
> 

Here is a bug report about it:

  http://bugzilla.gnome.org/show_bug.cgi?id=64532
 
The general reasons:

  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.
  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).
  c) to avoid re-entering the main loop on gconf calls; even 
     for round trips, ideally.
  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

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

> > And CORBA is getting you exactly nowhere there - it's just being used
> > to avoid fooling with sockets by hand. This is just a traditional text
> 
> Avoiding fooling with sockets by hand might well be worth it :)

That may well be true. ;-)

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.

Havoc