Re: questions about gconf future

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.