An analysis about a generic desktop application configuration management system
rich at xmelegance.org
Tue Apr 12 01:23:42 EEST 2005
On Mon, Apr 11, 2005 at 05:45:42PM -0400, Avery Pennarun wrote:
> If I want to use konqueror and evolution at the same time, it's a big PITA.
> If you don't have any problems like this, well, you're just lucky.
Fair enough - I like to stick to one desktop.
> That said, *only* unifying the underlying config API will not solve this
> problem. You also have to decide on a set of shared keys, which is a
> massive pain in the neck and requires entirely separate standardization
I agree, though a concept along the same lines as we use for interfaces in
KDE could help here (cf. the KTextEditor interface).
> > > * More easy to migrate from one host to another host
> > Again, not really a problem I've every encountered.
> I have. Keeping my laptop's KDE settings in sync with my desktop ones is
> pretty annoying. Example: I want different konqueror fonts, because my
> screens are different sizes.
That seems a bit different to migration. Surely the existing systems like
KDEDIRS can deal with it though?
> > > * Can be platform independent (there's many reasons why this is
> > > useful)
> > KConfig already is, what do you mean? I'm sure Gconf is too.
> Does it run on Windows? If it does, will it store things in the registry,
> where Windows people are expecting their configurations to be stored?
Yes and no repectively.
> (Of course, I'm not sure D-Conf is attempting to solve this problem. But
> that sounds like what the above requirement is asking for. UniConf can do
> it already, BTW, if you want.)
> > > * There's a need for an IPC system that can do signalling and that
> > > is widely accepted by most free desktop application developers
> > Well, I'd say DCOP. :-)
> "Widely accepted by most" might be an exaggeration of the current situation,
> but DCOP is pretty cool.
> > > * The system should be network transparant and an IETF protocol
> > > for configuration access would be nice.
> > Why? I think latency would kill network transparancy here, and I don't
> > see why the IETF matter either.
> UniConf's network protocol is extremely network-friendly and has been
> designed to minimize latency. It works fine. (To do this properly requires
> putting caching in all the right places, of course.)
> This is not to say you have to use UniConf - just that we've already proven
> that this can be done, so people who say it can't are just plain wrong.
I'll take a look.
> - D-BUS is not just for desktop stuff, and has nothing to do with X
> (although it could be extended to communicate over an X server instead of
> a Unix socket, since that makes sense on a desktop). My company will
> probably end up using it in an upcoming version of our server OS, and
> there's certainly no X server installed.
> So it seems likely that D-BUS will be acceptable to everyone, while there
> are a few reasons why DCOP might not be.
IIRC DBUS currently lacks some of the features of DCOP. That said, maybe
> > > * Glib and GObjects (chosen because it eases the creation of
> > > interoperable libraries)
> > Over my dead body.
> Don't worry, I'm sure this requirement won't actually happen.
Which? GLib or my death?
> > For me to be the least bit interested in this idea I need to see:
> > 1) Significant improvements for app developers vs. KConfig
> Notifications and network transparency ought to provide that. I think you
> should also add to your requirements, "No worse than KConfig."
I agree notifications and network transparency would be nice. Certainly for
the former, adding support to KConfig would be easier than any change of the
> > 3) No loss of easy of use (eg. by using chmod vs. SQL GRANT).
> If the new config system requires you to set up an SQL server, it will
> certainly fail. If it *allows* you to use SQL if you want, well, that's
> neutral to me.
I don't see a problem with allowing SQL, but think it will essentially
be a DB implmenting a tree which seems pretty silly.
More information about the xdg