An analysis about a generic desktop application configuration management system

[Dave Cridland]

On Thu Apr  7 20:16:25 2005, Havoc Pennington wrote:
> On Thu, 2005-04-07 at 20:32 +0200, Philip Van Hoof wrote:
> > Such a system needs a lot requirements. You can find some of them
> > here.
> > 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.
> 
> 
I thought GConf supported atomically setting multiple keys at once? 
This also occurs in ACAP, and I find it useful occasionally.

Also, if you provide a set-if-not-modified-since style API, you gain 
much of transactions without the locking or complexity anyway.

Agreed, though, that neither are true, RDBMS-like transactions, and 
also agreed that these aren't important.


> >       * There's a need for a default backend database format that 
> can
> >         store Unicode data in a tree-like structure or in a 
> structure
> >         that emulates a tree. 
> 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.
> 
> 
I'm neither sure that the format Philip describes can't be a text 
file, nor sure why transaction support makes a difference. I'm 
probably missing something obvious.


> >       * The system should be network transparant and an IETF 
> protocol
> >         for configuration access would be nice. 
> I don't think this is important. You might want a network backend
> eventually, but the only network communication needed is for the 
> backend
> to go out and fetch settings. You don't need network transparency
> anywhere else in the system.
> 
> 
Agreed that only backends need to worry about the network. But isn't 
that what network transparency means? That the applications consuming 
the configuration data don't need to know it's held on the network?

Any reasonably designed API should shield the application from the 
internals, though, but it's still a valid and important point. Just 
one I can't see how we could get wrong, now, with the prior art.


> IETF protocol is useless. Widely-used protocol people want to use, 
> maybe
> LDAP, could be useful.
> 
> 
If LDAP works for configuration, perfect. If not, another protocol. A 
standard, of any sort, has the advantage of more eyes in its design, 
is all.


> >       * The system should be integratable with source control 
> systems
> >         or other external tools for doing version control
> 
> If you use text files you can get this free.

Almost, but not quite. You'd have to issue a commit on every set to 
get it completely integrated. This isn't an impossible situation, of 
course - rollback to a cronned commit yesterday is a lot better than 
no rollback at all.

In a perfect world, the configuration system itself could perform 
version control, in effect, but none of them do as far as I know. 
(I'd not be surprised if Avery told me that UniConf can, though.)

Dave.