GNOME.org
 

[Colm Smyth <Colm Smyth ireland sun com>] Re: GConf





>To: Colm Smyth <Colm.Smyth@ireland.sun.com>
>Cc: robert.odea@ireland.sun.com, john.heard@sun.com
>Subject: Re: GConf
>From: Havoc Pennington <hp@redhat.com>
>User-Agent: Gnus/5.0803 (Gnus v5.8.3) Emacs/20.5
>MIME-Version: 1.0
>
>
>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.)

I don't think it causes a problem with update notification because I
assume that a schema change affecting the default value does not cause a 
notification (it would require a mechanism for the backend to ask each
gconfd process to check if the default value would have been used by
a client; if no overriding value existed in that client's database list,
then the default value is the one that the client would see).

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

The naming of a schema without a key so that it may be referred to 
elsewhere with a specific (or wildcarded) key is an equally
important feature of the changes I suggested. I'm assuming that 
applications will need to come with their own schema files and these files
will need to be able to re-use system schema information. 

>Are you proposing that the GConf API change here, or is it just
>additional syntax in the .schemas file?

A small API change would be needed to allow a schema to be named and
referred to for a key.

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

I agree with your concerns about latency. Although the design of
GConf permits a layered path of databases, ranging from centralized
enterprise-wide databases through workgroup, host and down to an
individual user database, since there is no 'map' to indicate where
keys may be found, a linear search through the databases is needed.
The enterprise database is likely to suffer most from network latency
but it is always searched for keys. A practial GNOME installation
may require enterprise databases to be mirrored locally on workgroup
servers.


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

Locking is not a problem from a technology perspective, but it
can affect the semantics of concurrent clients and in the case of
an update transaction may lead to deadlock depending on how it
is implemented by the specific database technology.

I've adopted the view that update notification is a 'nice to have' but
that apps should not rely on it once I noticed that the backend
interface provides no mechanism for databases to tell clients that an
update has been detected - it is up to gconfd to do notification.

There are other reasons for apps not to depend on notifications;
most existing database types don't make change notification easy
to achieve. SQL databases support triggers which are probably acceptable,
but I believe that LDAP is the most likely contender for enterprise
configuration storage. If you look at 
http://www.ietf.org/internet-drafts/draft-ietf-ldapext-psearch-02.txt
you see that a notion of a 'persistent search' is used. This doesn't
match very well with gconf's straightforward mechanism.

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

Correct me if I'm wrong, but I'm guessing that ORBit's name server
is located by looking at properties on the Xserver as name services
are reported to be tied to the user's X session. This appears to
be the only security and the means to prevent a user's gconfd from
being manipulated by another user, possibly remotely.

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

If you would like to make change notification a reliable feature, 
you need some backend support. Rather than requiring a backend
to do notification, it's possble to simply require backends to
store a list of current clients. Then when a gconfd client does
an update, it also notifies all clients (both those in the
gconfd user's session and other clients). The only downside is
that this only does notification if GConf is used to update
the configuration values; it would not work for other API's
(e.g. regular LDAP).

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

It makes sense as it is very straightforward.

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

I feel that it's not a good idea to create artificial labels for
database types; it's one of GConf's strengths that it applies a
simple algorithm and sysadmins can use the database-path mechanism
to create flexible configuration views.

I think it would be better to have a list of "root paths" associated
with each database.

e.g. 

EnterpriseDB: /schema, /gnome/applications, /gnome/bookmarks
Workgroup:    /schema, /gnome/applications, /mail/aliases
Host:         /gnome/filesystems
User:         /gnome/applications, /mail/aliases

When a value is read or written, the root paths form a high-level
map of the database list. Specifically when writing a value,
the workgroup database might be writable by regular users, but
the User database is used in preference so long as the key
is under one of the User root paths.

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

This is almost a must-have even for the first release, but I agree
that the design issues are more important. Including a search
method in the backend interface would be vital.

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

I believe that we can find simpler solutions to manage the complexity.

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

We could do reference counting; when the client count goes to zero, gconfd
self-terminates after 5 minutes.

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

Great, I'll use it.

>Havoc
>
>
>

Colm.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]