configuration system notes

[Havoc Pennington]

On Thu, 2005-04-07 at 12:18 -0400, Avery Pennarun wrote:
> In fact, those web pages do a pretty lousy job of explaining why, but I
> actually agree with you.  Three good reasons to enforce schemas at the
> frontend instead of in the daemon:
> 
>  - you can produce C/C++ headers from the schema, and actually load the
>    configuration content directly into an optimized local data structure
>    that will be faster and smaller while the app runs.  (Of course this
>    also gives you compile-time type checking in your app, which is nice.)
>    
>  - languages/apps that choose to completely ignore schemas have the option
>    of doing so, and they don't inherit any schema enforcement overhead.
> 
>  - it makes it really easy to write my UniConf backend. :)

Here is the explanation I mean:

"
      * the use of gconf is simpler
      * client apps are more robust due to emergency fallbacks
      * the client library can typecheck values for the programmer

It's also conceptually right, since schemas should match the client; the
client is the app that interprets the config values."

The other important reason is to avoid the need for scriptlets in
RPM/deb packages, I suppose those pages should mention that.

Note that none of these reasons are about performance, because there is
not a performance issue. GConf made the mistake of worrying too much
about performance in advance (and as a result optimized the wrong thing
- the real bottleneck is I/O due to having schemas mixed in with the
config data)

Havoc