Re: GConf debate ... - the ironic hub.

[Havoc Pennington <hp redhat com>]

Michael Meeks <michael ximian com> writes:   
>         So let me re-state the 'OH' position, I think it is a key to
> understanding, and I just saw the amusing irony of it.

Let me restate our position. You are confusing the heck out of people
I think.

We did an analysis/research paper on component technology, object
systems, and .NET, some months ago. In the paper we discussed a
hypothetical "universal shared runtime" design called Hub. Hub is a
purely hypothetical thing invented for the sake of argument in our
paper, a sort of "ideal native code runtime system" for comparison
purposes not just with component technology like Bonobo, but native
code runtimes such as that for Perl/Python and also VM-based runtimes
such as the .NET framework.

This was a private paper which we showed to you and Miguel in
confidence, because we wanted your opinion and wanted you to know what
we were thinking. I gather you took the paper as an attack instead,
but we were hoping to include you in our research and get your views
as people with expertise in the area.

The main reason we didn't make it public is to avoid creating
confusion around Bonobo. Because we think people should use Bonobo. So
we kept this topic in private mail.

Our conclusion was that to get an object system and runtime that could
be used to bridge XPCOM, GObject, Python/Perl/.NET etc., that is, a
runtime that could unify the entire Linux platform, we needed to have
features such as:

 - no more than C++ virtual function call overhead
 - dynamic invocation; zero stubs
 - convenient enough to use that you don't need convenience wrappers
 - X-style license, no LGPL
 - no dependency on GLib
 - no features above the base object system/runtime layer, i.e. the 
   design extends up to the level of IUnknown equivalent only

We also proposed including several quite different features from any
existing component system, because our proposal is for a full-scale
runtime, including features such as inheritance and garbage
collection.

Now, I am not going to go into detail or justify this, because I'd
have to post our entire 45 pages or so of text, plus a bunch of
references, and we are simply not ready to discuss it publicly.  So,
please don't start a thread on the merits or non-merits of the above
features, and whether or not they are needed to unify the Linux
platform, and so on. If it ever becomes appropriate then we'll post
the paper and that will make our argument.

But I will make several points about how this is different from the
GConf situation.

 A. It has nothing to do with GNOME, and is not a GNOME proposal or a
    GNOME project. The way it would become such would be for us to
    make an RFP sort of thing as I've suggested.  There will be no
    sneaking in or conspiracies.  We will not be checking this change
    into libgnome. And in any case it won't even be an RFP until some
    serious implementation work has occurred, which would require at
    least a year, assuming we had time to start on it now.

 B. Our proposed design is plainly completely different from Bonobo,
    and Bonobo blatantly cannot be modified in such a way that it
    meets the requirements we outline in our paper.  Thus there is no
    issue of gratuitous duplication of effort, but rather an issue of
    meeting all the requirements in the only way possible. GConf +
    wrapper in fact meets all the requirements I have seen for a GNOME
    config system.

 C. If we did make an RFP, then the RFP would be to bridge
    Bonobo to a newer technology, as has been done with UNO,
    while maintaining back compat. Which is precisely 
    analagous to using bonobo-config as a GConf wrapper, in order
    to keep back compat while using a new interface.

 D. We did send you our proposal and ask you about it, rather than
    simply checking the change into libgnome. And in fact we did that
    while still simply _considering_ and _researching_ the issue, in a
    non-GNOME context - what we sent you was our current rough draft,
    asking for comments and suggestions.

    On the other hand, bonobo-config simply appeared in libgnome one
    day and I didn't even know it existed (as reimplementation).


In other words, before anyone should care about this:

 - we have to actually implement something
 - we have to decide to propose it to the GNOME Project, 
   rather than using it for e.g. binding Perl and Python 
   to librpm and other intended non-GNOME-related uses
 - the GNOME Project with your participation would have to decide
   to move in this direction
 - we would have to have a bridge technology and backward compat
   plan for Bonobo

In any case, I think happening to share with you a paper that was NOT
about GNOME, about something which does NOT exist, asking for your
comments well in advance, is quite different from someone checking in
an implementation that did exist, which was not discussed in advance,
into libgnome.

I hope that clarifies to you how the two situations are different.

Also, I hope I have clarified that:

 a) we would welcome your technical input on our paper.

 b) no replacing of Bonobo will happen via back-doors or conspiracies;
    *IF* it were to happen, and I don't at the moment count on that,
    it would be by public discussion and with an extensive back compat
    plan.

 c) this Bonobo vs. hypothetical runtime issue is NOT what is deciding
    my views on GConf/bonobo-config. To me the key point is simply 
    that bonobo-config as wrapper is win-win and achieves all goals, 
    and the secondary point is that regardless of the technical
    issues, just replacing GConf with no discussion is unacceptable.

But I hope you'll agree with me that it's not worth confusing people
over this issue until at minimum we are actually planning to implement
a shared runtime technology. Which is *NOT* currently decided. That's
why we have not posted anything publicly.

And even if we post the paper, it *STILL* makes no difference to
Bonobo because our proposal is *NOT* for a GNOME Project but for a
project that includes people from Mozilla, Perl, Python, etc. - so it
would only become relevant to GNOME if/when GNOME discussed the issue
and decided to use our runtime as a bridge to those other
technologies. (Which is the point of it.)

For people who haven't read our research on this topic, I hope they'll
withhold judgment until they read what we've written. Or if we never
release the paper, I hope no one will worry about this issue, because
it makes no difference.

Thanks,
Havoc