GConf and bonobo-conf
- From: Havoc Pennington <hp redhat com>
- To: gconf-list gnome org, gnome-hackers gnome org
- Subject: GConf and bonobo-conf
- Date: 13 Feb 2001 22:52:23 -0500
Hi,
People are asking me about this "bonobo-conf" thing mentioned in
Miguel's gnome-libs blue sky web page, so I'll clarify what's up
briefly. I think discussion of the topic may have been in private
mail, it has been discussed and IMHO resolved.
There are two issues.
Issue #1
===
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.
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:
a) we were in an API freeze, and once we aren't, we need to
support the C API for backward compat. So the C API
can't be removed.
b) the C client library contains substantial logic; I don't want
to maintain two copies of it.
c) the very existence of gconfd and the CORBA interface to it is
currently abstracted. I do not want to give up this abstraction
layer. I think it may be worthwhile in the future to
have GConf talk directly to an LDAP server instead of gconfd;
it may also be useful to have it talk directly to just a flat
file, for embedded systems.
d) the efficiency gain from bypassing the current client library is
negligible. Efficiency is the only argument I heard for why
bonobo-conf can't be implemented in terms of the C API.
e) if people have time to hack GConf, or if I'm going to spend time
on patches for it, there are far more important features than
providing a different syntax for the API.
f) lots of people will simply prefer the C API, it already exists,
I haven't heard a reason why it's hurting anything. For those
who like a Bonobo API better, they can use the Bonobo API
and never know the difference.
g) there are situations where it's useful to avoid the Bonobo
dependency and still use GConf.
h) we have documentation, regression tests, etc. for the C client
API, gconftool is implemented in terms of it, etc. Documenting,
testing, and stabilizing the Bonobo API to the same degree would
in my opinion require at least a month of effort; the bonobo-conf
patch did not include this effort.
Anyhow, the "pros" column contained "tiny efficiency gain that hasn't
been profiled or shown to be a problem" and the "cons" column
contained a) thru h). Therefore I rejected the patch to implement
bonobo-conf by talking to gconfd directly, and requested that
bonobo-conf wrap the GConf C interface instead of replacing it. I
consider the matter closed unless a lot of the just-mentioned facts
change.
So bonobo-conf will exist if someone implements it, but the GConf C
API will not be deprecated and will continue to be supported. If it
turns out that no one is using the C API, then we can get rid of it
sometime, but I don't think that will happen.
Issue #2
===
The second issue is structured data storage in GConf. That is, right
now GConf only allows fairly primitive types to live at a key; ints,
floats, lists, pairs. You might want something more like a C struct,
or more like an XML document.
This feature was deliberately omitted from GConf 1.0 because it
complicates the implementation substantially, the right API is not
clear, and there was not time to do it while still delivering a
stable, high-quality library. It's something I would like to see a
solution to. I don't know the right solution; it's a hard problem.
Miguel's suggestion is CORBA_any, which may be right, but it's by no
means obvious to me that it is, and in any case it was proposed
post-API-freeze.
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
- don't use GConf to store documents and other large data; it's
just intended for the same purpose as gnome_config_* really,
and you wouldn't try to store some giant data blob
in gnome_config_* either. You could instead store e.g.
a moniker or filename pointing to your structured data in GConf.
- use a directory full of keys as a struct
- use gconf_unique_key() to get unique keys, and use a directory
full of those if you need a list of lists, or a directory full
of uniquely-named directories if you need a list of "structs"
- write serializer convenience functions for common types such
as GdkColor. Have the format for these standardized
by the GConf documentation. (i.e. the docs could suggest
that any color value be stored as a 24-bit RGB integer).
Some issues to consider when proposing a solution:
- notification of changed values has to be fast, and it sends
the contents of the value over the wire. Thus,
GConf values really can't be large.
- 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.
- 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.
- 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.
- I'd like to keep implementation of apps and of the GConf
admin/editor tool reasonably simple, so it gets done.
- I'd like to keep the implementation of GConf itself reasonably
simple, for speed/stability/robustness reasons.
- I do think GConf can afford to be less scalable in this area than
something like LDAP; desktop apps simply aren't all that demanding,
and GConf is really end-user-app-specific. It's not intended for
system or server configuration. It's just intended to store user
preferences.
There are other issues, I haven't thought it through fully, and that's
why you don't see a solution in GConf. Given the existence of
workarounds that are good enough in practice (after all,
gnome_config_* has been OK in practice), I don't see any sense in
tossing in a patch until we have some good experience with GConf and
have a better idea what the right thing to do might be.
I really haven't seen a good discussion of the issues from anyone, and
certainly I don't want to hear whinging about me not taking a
CORBA_any patch until such a discussion appears.
So, that's the deal, I hope that it clears up questions about
bonobo-conf.
In general, I think the following issues are more important and should
be the focus of work on GConf, rather than the above two issues:
- transaction support (make GConfChangeSet atomic)
- the GUI admin tool
- working solution to per-session, per-display, etc. settings
- a network backend such as LDAP
- improved test suite coverage
- finished documentation
- getting support for GConf in applications
- keeping things simple enough to use and implement
If someone is willing to hack on GConf for GNOME 2, I would encourage
them to tackle some of these issues. I'm not sure we should worry too
much about replacing or extending the API before actual user-visible
features have even been deployed.
Havoc
_______________________________________________
gnome-hackers mailing list
gnome-hackers gnome org
http://mail.gnome.org/mailman/listinfo/gnome-hackers
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]