An analysis about a generic desktop application configuration management system

[Sean Middleditch]

On Thu, 2005-04-07 at 21:46 +0200, Philip Van Hoof wrote:

> > I think you should dump the transactions requirement. It seems like it
> > should be useful, but in practice nobody has this and apps all work
> > fine.
> 
> Some of the applications that we looked at needed some sort of "undo"
> functionality for specifically their "preferences". In order to
> correctly undo preference setting actions, it feels right to have an
> atomic system with rollback functionality. 

That can be done client side.  An application can record which
preferences it has changed since the preference dialog was opened.  Or
are you talking about long-term system rollback?

> > If you dump the transactions requirement you can go back to text files.
> > Using simpler text files is the major reason that KConfig is better than
> > GConf for system administrators, so text files are a significant plus.
> 
> The support for text-files can also be available in the form of a tool
> to extract and import text-files from the system. I'm not yet convinced
> why the default and internally used backend data should be humanly
> readable or usable by external applications while the configuration
> system is running.

The biggest advantage to humanly readable backend files is that when
they get corrupt - and there's a chance they will someday for someone -
you can open up a text editor and fix it.  With a binary file format,
your binary tools are going to choke on the corrupted file and you won't
have many other options to fix it.

> Note that XML isn't suitable for source control systems (using diff on
> it is difficult and often fails).

XML is easy to deal with in CVS if you "pretty print" it.  xmllint
--format a gconf file and see how much easier it becomes to read and
edit.  It also depends on the exact schema you use; the GConf XML schema
isn't as friendly to hand-editing as it could be.
-- 
Sean Middleditch <elanthis at awesomeplay.com>