Re: GConf and bonobo-conf

[Miguel de Icaza <miguel ximian com>]

[ 
   I just want to contribute to the discussion with a few
   data points that maybe I did not communicate to Havoc correctly
]

I would like to clarify a few of these questions:

> A Bonobo interface to GConf; this is a great idea, I don't have a
> problem with it. So bonobo-conf is that. My only objection is if the
> Bonobo interface sacrifices usability issues that GConf attempts to
> resolve. These are mostly to do with system administrators, but also
> with users that want to do per-display, per-session,
> etc. configuration. Anyhow, the GConf goal of system manageability
> should not be sacrificed.

Havoc, I do not understand how Bonobo-Conf is any different from a
sysadmin perspective at all.  If you are going to say `command line
tools' then a client bonobo-conf program can be written to do this.

As I said before, the interest in the Bonobo-Conf moniker/engine
(which currently just happens to use GConf) is:

	* Support for arbitrarly complex data types (CORBA_any
          supports any kind of data type).

	* No new APIs created, the standard Bonobo::PropertyBag
          interface can be used in any language with CORBA bindings.

	* Flexibility in the moniker to extend the current design
          without many changes. 

Given that *currently* Bonobo-Conf uses GConf (because there is no
point rewriting the engine right now), any feature that GConf has for
sysadmins is present for Bonobo-Conf.  

	I am going to take a guess and assume that you think that
	Bonobo-Conf does not provide "command line tools" for
	manipulating the data.

	If this is the case, I can tell you that it would be trivial
	to write a command line tool to manipulate configuration data
	from the command line (specially now that we can take
	advantage of the nice Bonobo bindings for Perl, it could just
	be a script).

Now, with the points I mentioned before, I want to point out that
configuration data for per-session, per-display, system-wide can be
very easily added to Bonobo-Conf without requiring API changes, for
instance:

	config:SYSTEM/DefaultPrinter
	config:DISPLAY/Desktop/Background/Image
	config:SESSION/Blah

>From the Bonobo-Conf perspective, is just a matter of specing this
out.  

I do not understand how Bonobo-Conf `sacrifices system manageability'.

> I did object to one aspect of this. Miguel wanted to do bonobo-conf
_> instead_ of the GConf C API, i.e. talk to gconfd directly with
> bonobo-conf. I rejected this patch and insisted that bonobo-conf be
> implemented as a wrapper around the C API, for the following reasons:

The proposal I suggested was to have GConf support the
Bonobo:PropertyBag and Bonobo:Property interfaces as well as the
current internal interface.  

You forgot to mention in the `pros' section that using the Bonobo
interfaces API would give us:

	* Support for any language with CORBA support without the need
          to wrap the GConf C API for that language.  

	* GUI tools to edit PropertyBags is only going to get better
          (we have an initial stab at this in bonobo-conf).  

	* The same API used to talk to controls and configure them
          could be used to make system changes.

> There are reasonably good workarounds to the problem with GConf 1.0,
> including:
> 
>  - store an XML document as a string at some key
>  - store a serialized CORBA_any as a string; bonobo-conf
>    could do this transparently

It does this ;-)

So if you use BonoboConf, you get support for any kind of values. 

>  - values must be documented well, and editable via a generic 
>    regedit-style tool. So you would expect fields in a struct-like
>    object to be documented. Binary blobs that sysadmins can't 
>    do anything with are to be discouraged.

BonoboConf can do this ;-)

Because properties in PropertyBags are designed to be edited by a GUI
tool like Glade.  Providing a generic way of customizing controls.

>  - you don't want all the settings for your app stored in some huge 
>    struct; that defeats the ability of users and admins to separate
>    those settings so that some are per-workgroup, some per-session, 
>    and so on.

The reason for using arbitrarly complex data structures is not done
for "store everything in a single struct", but because nested data
types are more powerful than regular key/value pairs of data.

In GNOME all over the place you can find file formats where a complex
data structure has been "flattened" into the "address space" supported
by gnome-config.  GConf suffers from these problems (For an example of
such a file format, read the default.session file that ships with
gnome-core). 

That is why it is nice to manually store configuration data in an XML
tree, because you can describe data structures in their natural form,
without having to flatten/unflatten them.

>  - I question whether CORBA_any is the right answer in part because it
>    would be the only use of CORBA in the GConf API, and some apps may
>    not be using CORBA. I think an XML-based solution might be more
>    least-common-denominator.

CORBA_any is just handy, because the API to manipulate it is already
there.  I have no objections to an XML-based representation.

I would suggest to use the XML schema definition that is used by SOAP
to encode arbitrarly complex data types (and we can also stream
CORBA_any into those). 

>  - I'd like to keep implementation of apps and of the GConf
>    admin/editor tool reasonably simple, so it gets done.

I am confused, can you give me an example?

If it is what I think it is, then you should not worry, because you
can use monikers to get GUI elements to edit interactively data, or
fetch programatically accessible properties. 

Miguel.