An analysis about a generic desktop application configuration management system

[Philip Van Hoof]

On Thu, 2005-04-07 at 19:28 -0400, Havoc Pennington wrote:

> It isn't really the same effect. GConf does have the dump/load thing.
> 
> The issue is that UNIX admins already have elaborate hacks for pushing
> out text files and changes to same. The dump/load approach doesn't
> really work very well with most of these hacks.
> 
> There's also just a learning issue, where admins don't want to figure
> out a new system. GConf raises the learning bar higher than necessary
> due to the confusion with stuffing schemas in the system and general
> lack of UI design (for the command line tools and file formats), but
> still with readable text files there's a lot less learning.

Okay.. But most "admins" have backup-solutions that can handle creating
backups of databases. Well, were I'm employed the "admins" have backup-
solutions that do (but now I'm assuming that therefor "all admins" have
this, which is of course wrong).

SQLite isn't hard to backup or read from. Still, the configuration data
shouldn't be backed up by just backing up the SQLite data files. Simply
because it's possible some keys haven't been written yet (SQLite isn't
very good at concurrent writes, so a write-queue might be a necessity).

I don't know what other things "admins" would like to do with "the
internally used data thats responsible for keeping the settings
persistent between sessions". If it's version management, I'm confident
they scripted or programmed the support for it. So adding a single line
of scripting code to first create the dump, and then commit that dump,
doesn't sound to hard to educate or explain. 

cvs update configuration.txt
dconf-merge --merge-from configuration.txt
dconf-dump --output-to configuration.txt
cvs commit configuration.txt -m "Merge"

or in API it could be something like

mylibcvs_set_dir ("/tmp");
mylibcvs_checkout ("configuration");
mylibcvs_update ("configuration.txt");
dconf_facade_merge (facade, "/tmp/configuration/configuration.txt");
dconf_facade_dump (facade, "/tmp/configuration/configuration.txt");
mylibcvs_commit ("configuration.txt");



> I agree that we can ask admins to learn stuff if we need to do it for
> other admin benefits, or we can even add end user benefits at the
> expense of admins, but I don't think transactions are interesting enough
> to justify this since they don't really have big benefits for either
> desktop user or admin.

It's not only for transactions why SQLite is proposed. Agreed that
libXML will also fill in much of the features which SQLite delivers. 

However. LibXML isn't making it more easy for those "admins". Since XML
just isn't a format thats suitable for typical command-line commands
like grep, sed, cat, cut, tail, head. None of them are really usable on
XML files. Or you must be insane or be in love so much with those tools
that you can do XML-parsing with them on the command-line and in
seconds. (believe me, the typical "admin" doesn't love them that much)

So for the usual "admin shellscripts", XML is as unusable as any other
database format. Sure it's human readable ... but.

And finally. We don't want to be responsible for the state of the
backend database data at any point in time. Because that would mean no
caching, immediate writing, always reading from the file (rather than
caching a read in memory), always completely closing and reopening the
files. Because what if some "admin" indeed altered the file while the
configuration system is still running? And how is that configuration
system going to detect what that "admin" actually changed? etcetera ..

Very difficult to implement this (sure, not impossible .. but much more
difficult than just declaring the state of the internally used database
data .. "uncertain" and "not to be used for administrative purposes").

And there's many other issues ... (For example: I refuse to start using
file alternation monitors. It's a hack, not a solution).

Or how are you going to educate them to shut down that configuration
system when doing things with the data-files? Because that basically
means that they can't create scripts that will run at the same time the
user might be using the desktop. Simply because such a script would need
to totally freeze any desktop application using configuration.

> Trust me, I have no knee-jerk "databases bad, text files good" reaction;
> I'm all for upsetting orthodoxy. But in this case I don't think there's
> any point.

Okay. Well, the backend stuff is going to be abstracted to a separate
layer anyway. So it will be very easy to replace the backend with
something totally different.

Nevertheless it's important to iron out all the idea's and issues in the
specification.


-- 
Philip Van Hoof, Software Developer @ Cronos
home: me at freax dot org
gnome: pvanhoof at gnome dot org
work: philip dot vanhoof at cronos dot be
junk: philip dot vanhoof at gmail dot com
http://www.freax.be, http://www.freax.eu.org