[Havoc Pennington <hp@redhat.com>] Re: GConf

[Havoc Pennington <hp redhat com>]

---

• From: Havoc Pennington <hp redhat com>
• To: Colm Smyth <Colm Smyth ireland sun com>
• Cc: robert odea ireland sun com, john heard sun com
• Subject: Re: GConf
• Date: 21 Aug 2000 13:44:33 -0400

Colm Smyth <Colm.Smyth@ireland.sun.com> writes:
> Briefly, my main goals before GConf stabilises are:
> 
> - putback a working implementation of a GConf backend based around the
>   BerkeleyDB toolkit
> 

Sounds good.

> - propose some enhancements to the schema mechanism:
...
>      Note that this is a suggestion only. It may be less than trivial to
>      implement.
>

Yes, it could be quite hard to implement. (I didn't implement
"symlinks" because they cause a _lot_ of complexity, most importantly
when a key changes you need to do notification of listeners to not
only that key but any symlinks pointing at the key - I'm not sure if
this change causes the same problem.)

Right now multiple entries can of course have the same schema applied
to them (i.e. you can have multiple <applyto> entries for one schema),
but there isn't any way to do that automatically along the lines of
/gnome/mime/*/mime-type etc. 

Are you proposing that the GConf API change here, or is it just
additional syntax in the .schemas file?
      
> - test (and hopefully improve) performance of GConf when run against
>   more than one database
>   

All performance gains are a good thing (though once it's "fast enough"
I don't want to make the code ugly with optimizations). I'm kind of
expecting network latency to be the main performance issue, so we
might want to look at minimizing backend accesses (though of course
testing that would involve actually having a network backend!)

Anyway, sounds worthwhile.

> - alter the documentation to reflect the fact that backends must provide
>   some mechanism for concurrency control (e.g. locking). When users share
>   a GConf database (e.g. they belong to a group that are administered
>   collectively, or they share a common host machine), there must be
>   some mechanism to ensure that users can't overwrite each others
>   settings.
>   

Good. The XML backend does not address this; it assumes that only one
gconfd will access a writeable source, and that read-only sources
don't need a lock. (Of course this means that if root changes a source
that's read-only to users, users will need to restart gconfd to see
the changes, which is somewhat lame.)

The difficult issue here isn't really locking (most databases and such
will have that built-in), rather change notification. That is, if a
user changes a key, then all users' gconfd processes need to find out
about it. I believe backends will need to be able to call back in to
gconfd and say "change detected on key /foo/bar"), since change
detection will be different per-backend. I suppose failure to do
change notification isn't catastrophic, but it's certainly a nice
feature if it can be done.

If we can solve this, then we don't need to require a single gconfd
per home directory, and can instead have a single gconfd per user
session. The advantage of that is that gconfd is always running
locally, and sysadmins don't have to fool with allowing ORBit to open
sockets across the network. Could also have performance advantages.

For the XML backend it's going to involve some kind of polling
timestamps on files though, which is unpleasant (if nothing else, it
keep laptops from spinning down their hard drive).

> - document clearly the mechanism that GConf uses to select a database to
>   write values to (currently I assume it is the first writable database in
>   the user's list of configured databases, which may not be that same database
>   that the value was read from.)
> 

Yes indeed, right now it just picks the first writeable one. Best plan
I could come up with at the time.

Other plans are: 
 - as you suggest, put the key back where it came from; disadvantage
   is that I think you have to query all backends to figure out
   which one currently stores that key, which is potentially a 
   performance issue

 - add information to schemas which says "this key is per host", 
   "this key is per display", "this key is per home directory",
   "this key is per workgroup", or whatever. (Not sure in what 
   form this data should be encoded, to make it extensible; perhaps
   just have named "key domains" where we have some conventional
   domains and people can invent their own).

   Then you could mark a configuration backend to store values in 
   one or more of these domains. e.g. you could say "this database
   stores per-workgroup settings"

   This solution also will decrease performance, but it shouldn't be
   all that bad.

I have a "reinventing the wheel" sense here, perhaps there are
examples we could look at from other systems where similar problems
are addressed.

> What is your view on the relevance and timeliness of these activities? The
> BerkeleyDB work will take most of my time, but I believe that implementing
> the code to reflect any design changes that make GConf a better fit for
> enterprises is more urgent.
> 

These are certainly important issues, especially database selection
and locking, both of those are hard issues I've been thinking about.

Other stuff I consider important to implement, but more mundane than
the design issues we're discussing:

 - a regedit-style GUI for setting all this up, and editing keys, etc.
   This may require API additions to make it fast enough, I'm not
   sure. (Specifically, if we implement a feature that searches the 
   database for strings, which is often-used in regedit, the search 
   should almost certainly be server-side rather than sucking all 
   the data down to the GUI client.)

 - constant testing and test suite enhancement, it sounds like GConf 
   is just getting more complicated, and it needs to keep working

 - robustness against gconfd exiting or crashing; right now, in theory
   clients reinstall their listeners if they discover gconfd has gone 
   down, but I don't think it's totally robust, and they don't
   discover gconfd has gone down until they try to access GConf.
   Another possible solution is for gconfd to keep a log file, 
   and reload all the client listeners itself. 

 - life cycle management for gconfd; right now gconfd lives forever, 
   which is sure to get annoying if you have a machine with a few
   hundred users. I think this is as simple as exiting after a period 
   of idleness, but it requires the above-mentioned robustness against
   gconfd exiting.

 - A trivial thing I want to do is replace GConfError with a
   cut-and-paste of GError (from the glib unstable branch in CVS,
   gerror.h), this is going to be a large patch because it renames
   things all over the place, but shouldn't introduce bugs or anything
   like that.

 - keep documentation written and updated, of course.

Plus there are likely some things I haven't thought of yet. ;-)

Anyway, I'm thinking that the GUI can wait until post-1.4, but most of
this other stuff seems pretty important. If we can't solve all of it
we at least need to leave the API and file formats extensible enough
to allow us to add the new features later.

Since we now have >1 person working on GConf, I might start up a
mailing list for it - I'll let you know. That way all interested
parties can keep track of goings-on.

Havoc




 

---