Configuration API

Dave Cridland [Home] dave at
Mon May 3 17:16:15 EEST 2004

On Mon May  3 14:20:50 2004, Sean Middleditch wrote:
> On Mon, 2004-05-03 at 04:53, Dave Cridland [Home] wrote:
> > Couldn't the application simply add a further member to each struct to be 
> > used as a sort order?
> That would require the app to read in all the keys, sort them, and then
> select the index it wanted.  I'm not sure this is something real apps
> actually need to worry about, though.  Some examples of this scenario
> occurring in real life would be useful.  If any exist.  ;-)

The only instances I know of are related to ACAP storage of addressbook 
entries, bookmarks, etc. ACAP supports structures - indeed, it *only* 
supports structures - but it also supports server-side sorting and complex 
searching, as well as supporting virtual scrollbar stuff, all of which makes 
the point somewhat moot. And in any case, no application actually uses any of 
these features in the wild anyway, as far as I know.

Aside from that, I seem to recall that Havoc got a few requests for structure 
support in GConf at some point, but I've no idea what they were for, only 
that they were rejected, and structures never supported. (Along with, 
incidentally, binary data.)

Given that prior art in desktop configuration has not supported structures, 
it'd be more interesting to find cases where the application developer wanted 
structures, and has employed some workaround, then look to documenting that 
workaround for the general case.

I did start to consider what could be required in order to sensibly support 
structures. Server side sorting would be required, along with restrictions on 
what a member of a structure could be - you wouldn't want structures of 
structures, it just gets very messy, very fast.

But, although ACAP supports structures, I'd have to argue against them for 
our purposes - I think it'll complicate the support enormously, and knock out 
of the running several perfectly good contenders for backends.

I can't help but think that we have to, as our first priority, ensure that 
GConf and KConfig can rapidly adopt whatever we decide on with a minimum of 
fuss, otherwise we're whistling in the wind. While I'm a great fan of albino 
pachyderms of all varieties, we've got a good opportunity to unify 
configuration between desktops here, and it'd be a real shame if we made 
requirements which prevented uptake.


More information about the xdg mailing list