A draft for a standard for desktop configuration

[Avery Pennarun]

On Mon, Sep 12, 2005 at 11:26:38PM +0200, Waldo Bastian wrote:

> Comments for section 6.2:
> 
> Including type information at the transport level makes it impossible to 
> support backends that do not provide type information such as KDE's .ini 
> files. I do not see the value of typing at the transport and backend level, 
> especially since the type information provided covers only a subset of all 
> the desired configuration types in a configuration system. The schemas 
> already provide much more detailed type information about keys, including 
> range restrictions.

UniConf is all about the "everything is a string" way of thinking, so people
keep expecting I will be opposed to having data types at the protocol layer. 
But actually I think it's okay: a protocol that allows for data types allows
you to implement an "especially efficient" client and server if you really
want to.  Meanwhile, things like UniConf can just convert their data to/from
the requested types if you really want data to be in those types.

The trick is just to design the protocol such that it's okay to have both
getint() and getstring() work on the same (numeric) value.  You don't want
the protocol *enforcing* data types, just *allowing* them as an
optimization.

(I don't know if this proposal does everything like that properly, but if it
doesn't, it can just be fixed.)

Have fun,

Avery