A draft for a standard for desktop configuration

[Jamie McCracken]

Philip Van Hoof wrote:
> On Tue, 2005-09-13 at 11:20 +0200, Philip Van Hoof wrote:
> 
> 
> IMPORTANT!
> 
> I wrote this:
> 
> 
>>Note that this is a proposed/suggested implementation technique for a
>>daemon. It's not enforced by the specification. The specification
>>enforces only what it has to enforces.
> 
> 
> So I never said that the specification enforces you to implement the
> schema validation in the daemon. 
> 
> What is enforced by the (current) specification is that your infras-
> tructure needs to validate the type of the values.
> 
> So let's say your library has high level get and set functions like
> 
> "value = get ("/org/hello/pref")" and "set ("/org/hello/pref", value)"
> then the only thing that the current specification enforces is that the
> get will always return the type as specified in the schema, and the set
> will only accept value to be the type as specified in the schema.
> 
> How you implement that (in your library or in the daemon and backend)
> isn't specified in the current specification. And my previous E-mail is
> just a suggested implementation technique (it's not a specification as
> specified in the current specification, it's a suggestion of mine).
> 
> I repeat this because one person replied me personally with a rather
> angry e-mail where he tried to again explain me why it's a bad idea to
> do schema enforcement in the daemon.

I would also add that DBus is type safe by nature so whenever you pass 
values across it it validates the types for you. So its important for 
people here to realise that type validation is occuring automatically 
anyhow at both ends. It would also be impossibe for the daemon to pass 
values to the client as a variant without knowing the type of the value 
from the schema.

Of course if an app or KConfig wants to also do type validation at the 
client end then thats fine - no one is saying you can't (though you will 
be duplicating stuff that dbus is already doing).


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