Re: questions about gconf future
- From: Dave Cridland <dave cridland net>
- To: Joerg Barfurth <jub sun com>
- Cc: Discussion of the GConf library <gconf-list gnome org>
- Subject: Re: questions about gconf future
- Date: Tue, 06 Jul 2004 16:32:54 +0100
On Tue Jul 6 15:53:51 2004, Joerg Barfurth wrote:
Dave Cridland wrote:
On Tue Jul 6 04:22:24 2004, Marcin Antczak wrote:
2. Are there plans to change current schema structure? And for
example to use standard XMLSchema structures?
Ah, another I can answer. Goodie.
Syntactic validation does not lead to valid data, it's just one
step - the simplest - on the way.
XML Schema offers more than that. Besides syntactic validation of
data types it supports various constraints that can be used to
validate common semantic constraints.
Okay, so it does a little more than I thought.
An application may simply check the colour you entered is a valid
one, but might also check that the combination of that and other
colours provides sufficient contrast - such sufficiency being
defined, possibly, by a key elsewhere in GConf.
There is limit to the amount of automated checking that can be done
with reasonable effort. You wouldn't be able to check such
constraints in almost any database (except with custom triggers).
Indeed.
OTOH there is quite a lot of additional checks (datatype, range,
...) that can be done more generically and that cover most common
semantic constraints.
But a complete waste of time.
Let's assume we're talking about a colour. GConf could indeed
validate (on write, presumably) that a colour is a valid CSS3 colour
specification, for instance. The application then can read this,
knowing it's valid.
The application still has to parse it. Would you write an application
that parsed a relatively complex string, without error checking?
And it's worth noting that many apps may wish to retain whether the
user specified #FFF, #FFFFFF, #FFFFFFFFF, or white, or
rgb(100%,100%,100%), especially when it comes to re-presenting this
information in a dialog box, so we can't simply define a new wire
format for a colour.
But there is a place where enforcing schema-defined constraints is
useful and feasible: Configuration editors (like gconf-editor) can
use this data to inform their users about constraints on data, but
also to reject invalid input from humans. Another is validating
data files or registry scripts that are used to distribute
collections of settings.
I don't actually agree that we (and I'm counting everyone present as
human) should be prevented from entering invalid input, at least if
we're doing so behind the application's back, as it were. The
application should reject bad configuration, and certainly not enter
it, of course.
Think of how many times you've had to 'hack the registry' on Windows.
(Or how many times you hear of it, at least.)
Validation of registry files and scripts? I think that these
effectively fall into the category of execeutable content, and
therefore people should be trained not to run them, in the same way
we've trained Linux/UNIX users everywhere not to run arbitrary shell
scripts and commands from untrusted sources.
GConf is not alone in this decision, incidentally - I'm not aware
of any configuration system which does do validation except on
read, whereas I do know that the ACAP working group spent a
considerable time analyzing whether it was worth doing before
discarding the idea.
Same with OpenOffice.org. We even added something derived from a
(very small) subset of the XML Schema datatypes constraints
language to our schemas. But we don't use it to validate live
access to configuration data by applications. Instead the
information is intended for humans and generic editor tools.
How many times do those get out of sync?
Where validation would come in handy, of course, is within the
application, written in code, tied in with a parser.
If it were possible to, for instance, validate that
"rgb(100%,100%,100%)" was a valid CSS3 colour specification, and, on
top of that, hand you back some useful data structure you could then
actually use, then that would be a useful addition to the GConf
client libraries somewhere.
The problem is that these sorts of formats do change (in this case,
from CSS1 and CSS2), and maintaining binary compatibility would prove
an interesting challenge.
The advantage, in this case, is that applications which simply
handled a "colour" would seamlessly upgrade themselves from CSS1
through to CSS3 without any recompiling.
FWIW, KDE does something similar, in as much as the code required to
read in configuration is written, itself, by a schema-like file, but
of course changes to the code-writer require a recompile to handle.
Dave.
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]