Re: Configuration storage

[Tom Tromey <tromey cygnus com>]

>> (I'm not a big fan of the current config interface, either, but I'm
>> not going to do anything about it...)

Ian> Actually, it's not *that* bad.  I think that if you did it as a
Ian> server, the keys' naming convention would become much more
Ian> flexible than the current /file/section/key form (which is only
Ian> really a convention in any case: there's nothing stopping you
Ian> stuffing up someone else's config file if you choose...).

There are problems with the current interface.  Generalizing the
namespace won't work with the current implementation (you can't have a
key which has both a value and subkeys).  You might argue that this is
an implementation problem.  I think it's actually somewhat fuzzy; for
instance you could write code that assumes the namespace is limited in
the way it is.

Also, there's no way to arrange to be notified of changes to a config
option.  If your config options are done via a remote server, this
would be a natural thing to do.  This has real effects on how
application code is written, so adding it later will probably be
painful.

Ian> I thought the 'less than nice' bit was mainly that they were crap
Ian> and inefficient, rather than working differently to ORBit.  If
Ian> that's the case, then why should their being crap stop us using
Ian> them, since we're effectively in the prototyping stage?

The problem is that using MICO in libgnomeui would mean every Gnome
application would require 48M of RAM just to link.  So it's not really
a technical problem but a perceptual one.

I actually think it is a reasonable thing to do.

Tom