A draft for a standard for desktop configuration

[Avery Pennarun]

On Tue, Sep 13, 2005 at 12:50:26AM +0100, Jamie McCracken wrote:

> For example if I request the value of a rect (IE a struct containing 4
> ints) the daemon will need to read this from a DB as a string (say comma
> delimited as "1,2,3,4") and also read the type signature from the schema
> (for a dbus variant you need the type signature) then serailize that
> string into a struct containing four ints (which basically means passing
> the variant four ints to serialize). If the data from the DB did not
> contain four ints then we would not be able to serialize it ergo we would
> return an error instead of a rect.

This argument is kind of self-referential.  If the
backend/middleware/whatever would just give me the bloody string in the
first place, my app would be happy to convert that into an array of four
ints, and we would have avoided the whole problem.  If the backend refuses
to give me the string, then yes, all that other nonsense is necessary.

The only reason schemas are good for anything at all, IMHO, is that you can
compile them into data structures and enforce them at *compile time* of the
application.  That's really cool because it gets you perfect consistency
(assuming no third party is randomly messing up your config database) and
virtually free application-side validation (even if someone is).  As several
people have pointed out, applications have to validate their data, no matter
who else is *also* validating their data.

I think all this is how KConfigXT works, and it seems to be the idea behind
Havoc's ideas for GConf3 schemas.  Please learn a lesson from the people who
already screwed it up once :)

Have fun,

Avery

P.S. Does anyone else find the idea of parsing XML schema files as a way to
optimize away atoi() rather funny? :)