Re: questions about gconf future

On Tue Jul  6 04:22:24 2004, Marcin Antczak wrote:
> I have some questions about GConf future plans.
> 
> 1. Are there plans to use GConf for keeping customization 
> preferences for system services and apps?
> (for example - to replace /etc/sysconfig known in Fedora Core 
> distribution)
> 
> 
Well, in principle, there's no problem with doing that - but bear in 
mind that most programs are specifically made to read in 
configuration once at startup, and, in some cases, on a specific 
signal. (For headless programs such as daemons, this tends to be the 
otherwise redundant HUP. I used to work for a guy who thought this 
was universal, and once sent HUP to his login shell on a remote 
machine after changing his ~/.bashrc. Whoops.)

GConf, like a few other modern configuration systems, is designed to 
provide change notifications - the idea being that the data within 
the configuration system is the current working set. This is a 
different concept, and changing applications blindly to pull 
configuration once-only from GConf could confuse people greatly. 
[Yes, I accept this is a change of opinion. I'd like to see all 
configuration live, personally, but I've decided it's not worth 
persuing just yet.]

Besides which, you can't get at GConf until the system is quite a way 
along booting - potentially, you need full network access before you 
gain access, so the best method of obtaining the boot-time 
configuration would be to rebuild it into text files whenever GConf 
signals a change. And of course, it'd need very careful validation at 
this point.


> 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.

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.

The very first check could, in theory, be handled by GConf on a 
store, but then, realistically, the application would need to verify 
on read that the XMLSchema, or other validation information, is 
correct too. I suspect (although I could be wrong), that simply 
checking the value is simpler. I believe that an application would 
have to check this, incidentally, regardless of whether GConf 
validated the data, especially in the case where an erroneous value 
would render the application unusable, or insecure.

The rest are getting very, very complex for GConf to handle in a 
general way.

So a decision has been made that - while GConf supports the notion of 
attaching information to tell applications in broad strokes what data 
is expected, and tell humans very specifically what's expected - 
GConf does no validation whatsoever. So you could store 1 in your 
colour. Or ['zero','zero','two hundred and fifty-five'].

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.

Dave.