Configuration API

[Dave Cridland [Home]]

On Fri Apr 30 20:36:38 2004, Sean Middleditch wrote:
> 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'm not sure it *is* actually a use case, though. :-) But I appreciate the 
sentiment - that the lowest level backend may prefer to store a particular 
format in a particular way.

> 
> > 
> > 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.)
> 

What I'm loosely thinking is that most backends will be transforming the data 
into strings and lists of strings at some point anyway. Moreover:

1) The resultant types will be different between environments. KDE prefers 
>> QList<int> (or whatever), GConf prefers g_slist<int> (If the C purists 
will pardon me my C++ template syntax), and GConf wraps it in a variant type 
anyway. I would hate to think of all the possible permutations of a list of 
dates.

2) The code will be performing the same task in many different backends in 
the same environment. Therefore it might as well be the same code. So you'd 
have a single KDE 'data adaptor', a single GNOME 'data adaptor', etc. These 
could even map datatypes not present in those environments to native ones - 
for instance, a GNOME one could, for the moment, expand and unexpand paths 
into strings.

> 
> > (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.
> 

True.

> 
> 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.)
> 

Hmmm... I see.

Couldn't the application simply add a further member to each struct to be 
used as a sort order?

And if it's doing this, is there any need for structs at all? It's just 
increasing complexity, in a lot of ways.

Feel free, though, to substitute 'application' with 'upper-level API' at any 
stage.

Dave.