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/
_______________________________________________
xdg mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/xdg
