Notes from meeting at Red Hat, 31 Aug 2001

[Owen Taylor <otaylor redhat com>]

Michael came by Red Hat last Friday; we had a useful discussion about
various aspects of the devel platform and about getting GNOME 2.0
out. The following is an edited writeup of notes I took during the
meeting, with additions from Michael.

Regards,
                                        Owen


Notes from meeting at Red Hatn, 31 Aug 2001
===========================================

Attending:

 Michael Meeks, Jonathan Blandford, Alex Larsson, Havoc Pennington, Owen Taylor


The meeting started off with general/vague discussion of "What is
GNOME" and what the overall technical direction for the platform
should be, and then moved into more detailed issues. Notes on
the detailed issues follow.

General Idea
=============

 * The infrastructure we develop for GNOME covers a wide range of different 
    target uses:

    - Stand-alone apps (embedded apps, small tools, etc.)

    - The core 5 desktop pieces:

      Help Browser, Control Center, File Manager, Panel, Window Manager

    - Large office style apps (Evolution, gnumeric, etc.)

   Different subsets of our infrastructure are targeted at different
   pieces of this. We shouldn't demand that every 200 line tool use 
   Bonobo, or that large office apps use only GTK+.

   Since the core desktop is the most visible product of the GNOME
   project currently, we need to identify the part of the GNOME
   infrastructure that it depends upon. This is important when working
   out schedules what versions of platform components to use for
   a particular release.

On Bonobo
=========

A considerable amount of discussion was had about two problems run
into with Bonobo out-of-process components currently:

 - life cycle management
 - reentrancy during outgoing CORBA calls

No real conclusion was reached on these issues; they aren't trivial
issues.

For life cycle management, possible partial solutions include:
 
 - Monitoring connections, freeing objects when no more connections exist
   (this isn't CORBA compatible, but deviating from strict CORBA compliance
   in other areas may be needed as well.) Michael has plans to implement
   something along these lines for GNOME-2.0. There are potential problems
   if object references are passed around without keeping another remote 
   connection open. (Bonobo refcounting conventions may help prevent problems 
   here.)

 - Using external information such as provided by the X connection 
   for embedding components.

For reentrancy, discussed solutions included:

 - Not allowing reentrancy at all, going to threading. Michael was
   strongly of the opinion that this would just substitute deadlocks
   for unexpected reentrancy.

 - Adding hooks in the ORB for controlling reentrancy. [With ORBit2
   it should be possible to do things like:

    orbit_invoke_nonreentrant (object, "foo", ..., &result);

   though there would clearly be a performance hit.]

   GConf is probably the most pressing problem as far as reentrancy is concerned
   since it doesn't look like involves remote/reentrant calls but actually 
   involves such. It probably is possible to control reentrancy from
   GConf in the short term by using one-way methods and by doing some sort of POA-wide 
   or global stop_taking_connections() / start_taking_connections() call around outgoing
   calls.

   More general hooks are GNOME-2.2 issue.

The main conclusion that we came away with was:

 - In-process components should be used when at all possible, since they
   mostly avoid reentrancy and life-cycle issues. 

Reasons to use Bonobo:

 - The detailed type information about interfaces that CORBA/Bonobo provides
   the ability to do automated scripting language support.

 - Bonobo provides a good base for migration to a future lean-and-mean
   component system, whether that system is a direct descendent of current
   Bonobo or not.

   (Opinion from North Carolina partipants was that a clean break would 
   be important for migration to a simple object system)
 
 - In some cases out-of-process components _are_ needed. This might involve
   cases where the component has linking conflicts with the application
   or an incompatible runtime. (Think of a Mozilla component.)

Reasons not to use Bonobo:

 - A programmer who is mostly doing GTK programming will find a steep 
   learning curve when they are confronted with CORBA types, monikers
   and so forth. 

 - While wrapping a Bonobo API with C convenience functions can help
   shield programmers from learning about Bonobo, this gives a very heavyweight 
   result, and a nice GTK+ widget is often a more efficient and 
   easier to implement solution.

Conclusions on Bonobo included:

 - Bonobo should concentrate on being good for the things it is being
   used for. (Applications like Evolution, Nautilus.)

 - Widgets as small as the Nautilus throbber should _not_ be Bonobo components.

 - It would be good to get cross pollination going ... people at Ximian
   should do some work on GTK+-2.2, people from the GTK+ team should
   work with Bonobo, and so forth.

Another note:

 - BonoboPropertyBag currently involves a GClosure for all callbacks. The
   GClosure support should be a slow-path thing with a fast-path C-only
   call that is used in the normal case. (Implement closures in terms
   of C suppport, or separately, instead of implementing C in terms of 
   closures.)

GConf
====

 - GConf is the config storage mechanism for the GNOME desktop

 - bonobo-config and the GConf C library are both appropriate ways
   of accessing the GConf config storage mechanism, depending on the
   other API's being used within the application. This is an issue
   for the maintainer of a particular package.

Getting out GNOME 2.0
=====================

 - Owen will do 1.3.7 on Monday

 - Agreed that we should go with -DGNOME_DISABLE_DEPRECATED for gnome-libs
   instead of a separate compat library. (Alex is going to do some timing of the
   overhead of extra libraries.)

 - ditem moniker is being moved to bonobo-config by Martin