Glib/DBUS and GSettings

Ryan Lortie began the session by giving everyone an update on the hallway-track discussion regarding the availability of DBUS access inside Glib.

He began with a brief history of some precursors: gbus (from two different people), eggdbus, and now gdbus. There's a lot of problems with these versions including leaking implementation details through the API.

The first step to sanity and what was agreed upon was to merge GVariant in to Glib. GVariant provides support for DBUS's data types. Second, libgio will link to libdbus1, possibly via a GIO module extension point. Third, some of the best parts of gbus and gdbus will be picked and merged in to GIO.

There was a tangent about implementation details regarding which pieces of each of the DBUS binding precursors to take implementation ideas from. Another tangent shot off of this between Robert McQueen and Ryan Lortie regarding the features that would be needed to obsolete all of the custom DBUS solutions out there. (This lasted a very long time without much conclusion.)

A critical feature was requested by Colin and Ryan agreed: this new binding needs filtering and path registration.

Emmanuele pointed out that a tangent related to this work would be to put libunique in GIO on top of this new binding since many applications will want that feature, anyway. There was agreement that this was a good idea.

Ryan then demonstrated writing code using GVariant. Much happiness ensued.

Ryan then switched the session to GSettings. He said that there is a lot of excitement about GSettings: there's a desire to also add it to GIO after GVariant is merged. He began the GSettings discussion by going over the GSettings API. Some highlights included atomic changed signals for all settings changed at once, rather than getting a bunch of signals for each setting. There is not yet a filter function that would allow inverting a value coming back from GSettings. (For example, allowing you to show the opposite value in a bound UI widget.)

There was a question from Colin about whether it would prevent recursion: it does.

Then, Ryan showed an example Vala program using GSettings. Mandatory setings are supported—during the widget binding step, sensitivity will be set to off if the key is mandatory.

He demonstrated the schema format underlying GSettings: it's a simple format supporting inheritance with a simple plain text format.

A side question was about how Sabayon could support this. Ryan replied that the method would be to monitor the root of dconf for events and capture them there.

Ryan switched to demonstrating dconf to replace gconf. He went over the API as it stands currently; it's simple.

There was a question about the case where a user has an UI open when a lock gets activated by a system administrator. There's no support for the notifying the UI that the lock has been activated while it's open. A tanget spawned about how a user could get admin. privileges from the UI; Ryan will be adding PolKit support soon.

Someone asked about performance. Ryan said it's 10-50x faster than gconf on reads. Ryan discussed some of the implementation details that made writes high-performance, as well.

There was a question about synchronization of writes to avoid a race in a reading application. The dbus writer process uses fsync() a lot but you don't care because it's not blocking your application.

There was some concern about multiple users using the same home directory (a coffee shop, for example). Ryan didn't think this would be an issue but it doesn't make sense to do this anyway; he couldn't think of any application that repositioned a window based on notification that the state stored in gconf had changed. But, he recommended doing what others are doing: clone the pristine home directory on login.

Someone asked about doing regression tests of applications by setting the proxy settings in gconf/dconf without affecting the user session. Ryan suggested doing a custom GSettings plugin that redirected the requests to a temporarily database.

There was a tangent about allowing launching applications via a dbus call. There was some thinking that this could be a good idea but that some work would have to be done to make sure that launching the application the traditional way would have the same kind of interface.

Ryan described the plumbing of the default database. A question related to this topic was about how to do distro. packager overrides of upstream defaults. Ryan suggested modifying the schema via a package patch rather than having vendor-specific defaults databases on the system aside from upstream's default database.

He returned to the benchmarks they've run. Another big win is that dconf is only running during the writing process—even then, the memory consumption versus gconf is an order of magnitude smaller.

There was a worry expressed about NFS home directories. Ryan replied that there is a bug because of fsync() but he's working on it, actively. It's going to be hard to fix but he's committed to finding a solution.

He's going to be putting the documentation on library.gnome.org. There will be some documentation on how to do module migration in the future.

Finally, he wanted everyone to know that they are working on a gconf to dbus bridge. It runs some simple applications right now but there are some serious problems to solve. Help is needed especially with this part.