Re: Getting libgnome* into shape

[Havoc Pennington <hp redhat com>]

Joe Shaw <joe ximian com> writes:
> Seriously, though, the bonobo-config stuff doesn't add any API because
> it's all done via monikers and the propertybag interface that we're
> already committed to. I suppose there's a decent chance all of that
> stuff might not meet our needs at some point in the future, too, but
> then we're talking about more or less completely redoing the platform
> (again).... At what point do you draw the line?

<random aside>

I've seen this repeated several times - I would like to point out that
if you have a string that you parse, it still constitutes an API.

Let's use a popular #gnome joke as an example. Say I have the function
strcmp():

 int strcmp (const char *a, const char *b);

So I change this to a moniker:

 "libc:strcmp:string1=foo,string2=bar"

I do not now have less API. I now have an untypesafe ad-hoc scripting
language.

Clearly the joke is a bit overblown. But just because you support 2000
features using the same single C function or CORBA method, it does not
mean you somehow have less API. It just means the compiler will not
help app developers detect breakage in the API. I have to support
"libc:strcmp:string1=foo,string2=bar" without breakage for the
forseeable future; in fact it's more discouraged to break this, since
all warnings/crashes will be at runtime not compile time.

So let's take this to the actual situation, instead of the ridiculous
joke example. 

I would agree that if we have only config: that we haven't added any
API, relative to the situation where no GConf exists, because we've
recycled property bag. [1]

However, bonobo-config includes a number of monikers that are not
config:, and it includes the new sorts of notification events, and so
on. The fact that these things are done by changing the strings passed
through the Bonobo API does not mean it isn't API. xmldb: is a whole
new feature to support; the new kinds of event and moniker implemented
in bonobo-config are certainly API. The fact that the API isn't
specified in the IDL or in C headers is really not relevant.

Now, does this mean I think C APIs are perfect? No. IDL has the
advantage (and occasional disadvantage) that it enforces actual
encapsulation. C does not have that. IDL has disadvantages as well:
for example, no implementation inheritance. Strings have the advantage
over C that they can be more convenient and/or expressive, i.e. if I
need to allow a complex specification it may be easier to do this:

 gtk_label_set_text (label, "<span font='foo'>This is <b>bold</b></span>")

instead of:

 gtk_label_set_text (label, "This is bold");
 gtk_label_set_font (label, 0, -1, "foo");
 gtk_label_set_bold (label, 8, 12, TRUE);

and the second is also i18n-broken. But at the same time strings have
disadvantages, namely they are not typesafe, they impose a runtime 
performance penalty (bonobouihandler *cough*), they make it hard to 
change an API since the compiler can't catch it, and they are not
self-documenting since they are their own mini-language, not a
straightforward use of existing prototype methods such as C or IDL.

   [1] I would still maintain that there was extra stuff added to core
       bonobo purely to support bonobo-config, but let's ignore that
       and agree that plain config: doesn't add API. Also, I am
       ignoring the fact that we already shipped GConf with GNOME 1.4,
       so claiming that GConf adds API is in fact a logical
       impossibility - the API is already added, so cannot be added
       again.

</random aside>


Hmm. So, extending on this, let's venture further to the heart of the
matter as outlined by Jacob. i.e. do we move wholesale to CORBA.

In addition to the inherent issues with strings and IDL, GNOME has
some issues with our particular implementation of them; namely, even
in-process, CORBA is a bit too heavy for a noticeable subset of
uses. It's also too inconvenient for a noticeable subset of
uses. Finally, the combination of GObject + CORBA used in our C
bindings is a complexity overload no mere mortal has any hope of
understanding; both things were already (substantially) overengineered
by themselves, combining them is like doing advanced topology proofs
while juggling on a unicycle.

That is why our component technology can't possibly entirely replace C
APIs, or become as pervasive as UNO or XPCOM are in their respective
applications.

Long and short of it is, C APIs are not going away, and if we want to
deliver a good desktop that's not too bloated and serves users well,
in a timely fashion, converting everything to CORBA is in no way a
good idea. Using CORBA where appropriate is just fine; we need Bonobo
for embedding panel applets, Nautilus views, and other kinds of
pluggable modules when appropriate. But it's not a component system
that can possibly fulfill the dream of components everywhere.
Moreover, when used in a distributed fashion (out-of-process) it
currently has severe problems with lifecycle management that render
the desktop noticeably broken.

Michael thinks Bonobo can be fixed in-place by gradual evolution; I
think he is wrong, it would require tons of breakage. It's a simple
technical disagreement.  But even if Michael is right, I think we
should use it pervasively _after_ it is fixed, not on the promise that
it _will be fixed someday_. For now we should just be trying it out in
a few places and using it when we really need the features and so on.

So what is the practical upshot of this? Simply that we haven't
escaped C. For me, C is still more convenient and robust, and Bonobo
is still too slow and unreliable. So I am not enthusiastic about
Bonobo. I think using it in GNOME should be confined to cases where we
need the out-of-process support, because it's a better solution than
ad hoc hacks for that.

Is my view predicated on a replacement for Bonobo appearing? No.  I
think it is possible to write a component system that could be used
more pervasively; people have done it. However, my objection is not
that Bonobo is a suboptimal component system; my argument is that
Bonobo is not a component system that can be used pervasively,
therefore we should not try to use it pervasively. i.e. the argument
is about properties of Bonobo as it currently stands, not about
relative comparisons of Bonobo vis-a-vis other systems.

Finally, in my opinion, while a component system is cool, C is _good
enough_ to deliver an excellent desktop to users, and focusing on the
desktop instead of the platform would go a long way toward making the
desktop better. We should save the world once not twice.

In fact just the fact that Bonobo _causes this recurring argument_ is
enough reason that we should have restricted its use long ago. It's
clearly too controversial to go into the core, and if we're going to
have controversy it should be about user features, not about platform.
Maybe when Bonobo is better-proven and more mature it won't be
controversial anymore.

So, I have no idea how many people agree with the above; or how many
people even have the knowledge to have an opinion or care; or
whatever. I'm sorry that some people have repeatedly presented "Bonobo
is the way" as the Official GNOME View (while maybe some core hackers
don't agree), and that has been interpreted as "Bonobo must be used
everywhere." Because I think the more subtle view is "we should use
Bonobo when it makes sense, and understand the tradeoffs."

But that's where I'm coming from. In the end I want to ship a working
desktop that has a nice UI and I want to ship it frequently enough
that I actually get to use the improvements. I just honestly, on a
technical level, do not see how using Bonobo pervasively is helping to
do that.  Please convince me!

In the meantime, yes, as Jacob points out, there is a fundamental
conflict, because "Bonobization" has to touch every API and app, and
every one it touches broadens the impact of Bonobo's problems, or
makes things beautiful, depending on your point of view. So this
argument has no hope of going away.

I'm hoping we can resolve this. Maybe the answer is to write every API
twice, as C API and as wrapper. That's the best compromise we could
come up with for the config system. But for that compromise to work we
have to let individual hackers choose whether to use the wrapper or
not, we can't try to standardize on wrapper or wrappee.

Havoc