A draft for a standard for desktop configuration

[Dave Cridland]

On Mon Sep 12 23:57:39 2005, Jamie McCracken wrote:
> 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).
> 
> 
Except that the application already has to do validation and defaults.



>> 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.
> 
> 
So why enforce the schema anywhere but the application, if it has to 
do it anyway?


> [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).
> 
> 
But that functionality is already duplicated in the app. I'm 
certainly not going to suggest putting it in three places, I was 
angling for just the one.


> 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).
> 
> 
Doesn't matter - it's the apps that either handle the data or don't. 
Seems fair to let them decide what's legal and what's not. That's not 
to say that schemas are wrong, just that the enforcement of them is 
both futile and a waste of resources. After all, 99% of the time, 
it's the application that put the data there in the first place. If 
it can't understand what it wrote, my bet is that it's ever so 
slightly buggy. :-)

They're great for when you want to hit GConfTool et al, of course, 
but the only reason I can honestly think of for enforcing validation 
in the system is as a nanny-method of trying to encforce that they 
exist.

It's not the same as database work - there, you need multiple layers 
of validation, for various different tasks, because otherwise all 
hell breaks loose. For configuration stuff, the application either 
understands the semantics of the configuration data, or doesn't. If 
you input garbage into the configuration store, it really doesn't 
matter - the integrity of the data is still just fine.

Yes, of course the apps will end up switching back to their default 
configuration, but that is, we hope, perfectly usable. That's 
certainly not the same as if the data integrity breaks down on a 
large database.

I have to say I'm unaware of any existing configuration system that 
does do anything other than application-level validation - the 
argument that validation is vital is therefore a little weak to me.

Dave.