Orthogonality of gconf-plans frontends and backends
apenwarr at nit.ca
Fri Apr 8 03:32:04 EEST 2005
After all the discussion on this list lately, an in reference to Havoc's
gconf "Sketchy Specification" article:
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++,
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.)
More information about the xdg