Re: GConf and bonobo-config - some ideas

[Havoc Pennington <hp redhat com>]

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

Havoc