Orthogonality of gconf-plans frontends and backends

[Avery Pennarun]

Hi all,

After all the discussion on this list lately, an in reference to Havoc's
gconf "Sketchy Specification" article:

	http://www.gnome.org/projects/gconf/plans-spec.html

It seems to me that he has successfully broken the problem into two
individually solvable parts.

 1. The backend, which gets/stores data and serves it (along with
    notifications) to you via DBUS.

 2. The frontend (or "client API"), which talks to the backend over DBUS on
    your behalf, and handles schema loading and enforcement.

It seems to me that no cross-desktop configuration system will share the
same #2 between desktops; Gnome users will want a C or C# API based on
glib, while KDE users will want a C++ API similar to KConfig, for example.

Meanwhile, #1, barring a few details like statelessness, already exists in
the form of the UniConf-DBUS server.

It seems like a valid upgrade path for GNOME, at least, could be:

 - Adapt UniConf-DBUS to fully implement #1.  Adjust the DBUS messages being
   used until they're agreed upon by everyone as a standard.  (It's better
   to produce an implementation and then worry about standardizing the DBUS
   API; then we have something concrete to talk about.)

 - Construct a new #2 with an identical API to current libgconf; in other
   words, a drop-in replacement that talks to a DBUS server.

 - Eventually, add the new features like client-side schema enforcement to
   #2, which in any case will be done totally differently between C, C++,
   and C#.

What would be the barriers to such an implementation being accepted by the
GNOME project?  If they're relatively low, I might be willing to volunteer
for this.  It sounds like it wouldn't be too hard.

(KDE is also welcome to join the party, of course - I've written a UniConf
KConfig backend before anyway - but since AFAIK Gnome already includes DBUS,
they sound like an easier first target.)

Have fun,

Avery