Re: questions about gconf future

[Joerg Barfurth <jub sun com>]

Dave Cridland wrote:

> 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  [SNIP]

I agree with Dave that there is a very big 'but' here. For various 
reasons gconf (the entire infrastructure) is very much oriented towards 
managing configuration data for user applications.

Changing system applications and services, which currently use various 
configuration mechanisms (often centered around historically grown text 
file formats), to use a unified API for their configuration data access 
could be a worthwhile (but huge) effort of its own. I doubt this 
interface would be identical to the gconf API though - much less its 
implementation.

Such an API would be useful to get some of the things gconf does in the 
desktop application space now, like provide a hook for instrumenting and 
auditing or achieving some backend transparency. But configuration 
semantics and process lifecycle of desktop and system applications are 
sufficiently different to justify different APIs.

On the other side unifying and simplifying the way system configuration 
is managed by a user is also a useful goal. There are various ongoing 
projects to this end. GNOME has the Gnome System Tools project and 
freedesktop.org hosts the somewhat more ambitious config4gnu project 
with similar goals. These projects have in common that they try to 
decouple the administrative frontends from the file-format savvy backends.

On this end it might make sense to ultimately unify UIs for managing 
system configuration and for administrative management of gconf settings 
in one common console and with a common set of UI paradigms. It would 
also be helpful to standardize on one set of middleware interfaces and 
protocols upon which various infrastructure solutions (remote, 
distributed, delegated management) could be built.

So there are unification goal that are worthwhile to pursue. But it 
won't be as simple as using gconf more or less as is for system 
configuration.

> > 2. Are there plans to change current schema structure? And for example 
> > to use standard XMLSchema structures?

OpenOffice.org has it own configuration schemas. It uses schemas much 
more pervasively than gconf and the schemas have somewhat richer 
semantics. We borrowed some pieces from XML schema (in the datatype 
department) and maybe could use more. But we refrained from using XML 
Schema directly for defining the schemas. Instead we use a special XML 
language that is directly addressing the problem domain.

Using XML Schema in full generality leaves you with the problem that it 
is too general and it is hard to delimit and recognize the set of 
acceptable XML schemas. It also requires a complete XS validator to 
validate, whereas a more restricted languge can be more completely 
understood and enforced by simpler tools. OTOH it could be useful, if 
schemas can be transformed into XML Schemas suitable for validating the 
data files with reasonable effort.

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

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

OTOH there is quite a lot of additional checks (datatype, range, ...) 
that can be done more generically and that cover most common semantic 
constraints.

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

Agreed.

If you mix in the possibilities of updating software versions and that 
people might still change stuff manually there no way to really ensure 
that existing data fulfills all currently known constraints.

Having the configuration system (i.e. gconf) validate data on read is 
impractical. Firstly it causes quite some processing overhead and 
possible performance problems. Secondly the configuration system really 
cannot decide how to handle such an error. Just bailing out with an 
error may amount to a DoS for the client application.

Thus clients have no choice but to validate themselves.

I also agree that validating on all writes in the configuration system 
itself does more harm than good. In general one should consider the 
application that actually uses a setting as the ultimate authority. 
There also may again be performance problems with this.

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.

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

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.

Ciao, Joerg

--
Joerg Barfurth              Sun Microsystems - Desktop - Hamburg
>>>>>>>>>>>>>>>>>> using std::disclaimer <<<<<<<<<<<<<<<<<<<<<<<
Software Engineer                         joerg barfurth sun com
OpenOffice.org Configuration          http://util.openoffice.org