Dave Cridland [Home]
dave at cridland.net
Mon May 3 19:17:07 EEST 2004
On Mon May 3 16:56:51 2004, Lars Hallberg wrote:
> Dave Cridland [Home] wrote:
>> 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.
> I think the API can be prety flexably. If ther is *one* app that uses som
> complex structur in ther config files, we might consider suporting it, but
only that bakend need to suport it! Of, corce - this might more be a problem
for the frontends, that have to suport every feature from every backend.
Argh! No! If we don't have a consistent data model which is supported across
all backends, we're doomed. I think this is easily achievable between KConfig
and GConf, with only mild alterations to both.
> On the other hand, a front end can resort to string representation of some
> uncommon types, and lett the backend do the syntax checking (if we make
sure the API *alow* every key to be treated as a string as an alternative,
regardless of actual type).
Which raises an interesting question - is the datatype soft or hard? Meaning,
can an application say 'give me the value of this key as an integer'? ACAP
does this to some extent, but for our purposes, I'd say no. Moreover, I'd say
a backend shouldn't be handling validation - that should always be the job of
the application using it. Apart from anything else, type checking is a simple
addition to the validation that has to happen anyway.
> Actuly, the whole API might be strings wher typ info is only used for
> syntax checking. Then helper libs on top of the API can provide nativ
datatypes for different environment.
I've suggested something similar elsewhere in this thread, at least as far as
native type support is concerned. I'm not wed to it, mind, and I'm well aware
that such types as a list should be easy to support in any backend without
recourse to converting the entire list into a single string.
Sean Middleditch also suggested backends might be queriable for which
datatypes they support natively - this is also quite sensible.
More information about the xdg