Re: GConf and bonobo-config - some ideas

[Dietmar Maurer <dietmar ximian com>]

Havoc Pennington wrote:

> Dietmar Maurer <dietmar ximian com> writes:
> >
> > That was not my question. If the list is the only example where it is
> > usable to use schemas, then there are others ways to solve that problem,
> > i.e. we can associated the documentation with the directory (and not
> > introduce a complex data type). A default value makes no sense anyway.
> > So I am really interested if there are more such scenarios?
> >
>
> The only motivation I can think of for dynamically creating key names
> is that you want to have more than one value stored. Otherwise you'd
> use a single key name. So no, I don't think there are more.
>
> Dynamic keys aren't the motive for schemas though, just the motive for
> allowing dynamic schema application - the basic reason for the idea of
> "schema" as a datatype is that you may want several pieces of
> metainformation about a key, such as docs, default value, application
> that "owns" the key, and so on, whatever is in the schema. It seems
> cleaner and more extensible and robust to put that information in a
> single blob.
>
> You could say that by convention docs are at /docs/<key> and
> defaults at /defaults/<key>, etc. (and GConf manual does say you
> should put schemas at /schemas/<key>, but doesn't rely on that).
>
> But if you were e.g. trying to move your schemas from one database to
> another, it seems less annoying to deal with single values than N
> magic directory conventions (to me anyway).
>
> There's no problem supporting this in bonobo-config, right, since you
> just make a struct type for schemas and store them as a CORBA_any.  I
> just don't see a /docs, /defaults, etc. convention as noticeably
> easier to implement than a schema struct.
>
> I guess the hard thing to implement is "attaching" the schema name to
> a key; I don't know that this is required, maybe it isn't. As I said a
> /schemas/<key> convention is already encouraged by the GConf manual.
>
> I'm not clear on exactly what you're asking maybe...

So there is no need to make the mapping between a key and the schema
configurable, right? It is then simply useless to store that mapping with the
key. And you can simply use a separate database to store the schemas, which
is more consistent. I think the simple bonobo-config model can do everything
we need (although I am not 100% sure, maybe you know some cases where it is
not sufficient).

- Dietmar