A draft for a standard for desktop configuration

[Jamie McCracken]

Dave Cridland wrote:
> 
> If schemas are local, then a remote configuration server cannot 
> provide defaults sourced from them.

It can cause there's a local daemon present. The config system is like a 
traditional three tier client server database application where the 
clients (think GConf/KConfig) are very very thin, the middleware is a 
thicker daemon (which does all the validation and schema handling) and 
the backend is just a local database or a remote one or LDAP etc. Its a 
tried and tested design that is commonly used in enterprise software 
(like J2EE).

> 
> Personally, I feel that sane defaults should be either generated by 
> the application itself in the absence of data (in which case, they're 
> only documentation in the schema) or handled by stacking (which 
> complicates application installation).

Schema based defaults are only one layer. There should be emergency 
fallback values available in any well designed app in case a schema is 
hosed.

[snip]

> Section 6.1:
> 
> Personally I have a serious problem with validating on the server. 
> There are so many pitfalls and security issues here that I'd much 
> rather see the application validate. It is always more aware of 
> correct values than the server. Invalid values should be ignored, 
> replaced with defaults, or whatever else is most suitable for the 
> application.
> 
> Some cases where server validation fails includes network 
> environments where different client hosts have different application 
> versions on them.

Server validation is still local (IE on the local daemon). Read and 
write validation (types) is done automatically by serialization and 
deserialization of the DBUS Variant in the daemon and the backend will 
just chew strings. No need to duplicate this functionality in the 
client. The Client never accesses the schema directly (perhaps with the 
exception of a tool like GConfTool which would read schema descriptions).

Daemon validation is also sensible here because you can have multiple 
different clients (GCOnf and KConfig) with potentially different bugs so 
it would be wise to do all validation in one common place on the server 
anyhow (as you would in any well designed and robust client/server 
database application).


-- 
Mr Jamie McCracken
http://www.advogato.org/person/jamiemcc/