Configuration API

[Sean Middleditch]

On Fri, 2004-04-30 at 15:19, Dave Cridland [Home] wrote:
> I can't actually see that being possible, unless a key's datatype is codified 
> somehow very early on - otherwise you'll have a SQL table with a huge number 
> of columns, of which one will be used depending on the datatype.

Yes, I stretched very hard for that example.  ~,^  It was just an
example of one possible use case, thought.

> 
> I do think most backends will be able to handle lists, though. Arguably, a 
> backend could simply tell some upper layer what fundamental formats it 
> supports, and let the upper layer handle specific datatype handling.

Personally, I'm of the opinion that it's better to keep the upper layer
lite and simple, and push as much of the work into the backend as
possible.  The backend knows best what it needs, it's best suited to do
whatever conversions it needs.  It's not like we'd be adding any new
fundamental data types down the road.  (If we actually select a good set
of them up front, we'll never need to.)

> (GConf also uses per-locale defaults, although I'm not sure how much these 
> >> are used in practise. I really ought to examine GConf usage a bit more - 
> I'd really like it if pairs vanished, for instance, since pair<int,string> is 
> more complex to handle than list<string>)

With the addition of a struct type one wouldn't need a specific pair;
it's just be a struct with an int and a string sub-keys.

And based on that earlier discussion... are structs _really_ needed, or
should the API just provide a few functions that make it very easy to
simulate structs in the key heirarchy?  I.e., where we might have a list
of structs in a more complex model, a simpler model would just have a
set of sub-trees and a method to query the names of those trees.  (i..e,
give me all the sub-trees in /myapp/list-of-structs/)  The only problem
I could see with that approach is that where a list would provide
guaranteed ordering of items (at least that's how I think the list
should/would work), sub-trees would *not* have this quality (this is a
sensible design choice given how we want pluggable backends, and many
such backends could not support this quality).  Anyone needing an
ordered list of complex data types would, without having structs, need
to compose a list that simply held the names of the aforementioned
sub-trees, and manually keep them in sync.  (not pretty.)

> 
> Dave.
> 
> _______________________________________________
> xdg mailing list
> xdg at freedesktop.org
> http://freedesktop.org/mailman/listinfo/xdg
-- 
Sean Middleditch <elanthis at awesomeplay.com>
AwesomePlay Productions, Inc.