?

Log in

No account? Create an account

Previous Entry | Next Entry

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.

Comments

( 6 comments — Leave a comment )
ext_209896
Oct. 11th, 2009 07:39 pm (UTC)
This makes me wonder: why would someone want to put something like libunique (which is conceptually unrelated to querying file information, listing directory contents, launching files, volume management and streaming) or GSettings into GIO?

Wouldn't it make more sense to put the D-Bus and libunique stuff into their own GLib module rather than into GIO? I'd personally prefer to keep the I/O and VFS stuff separate from the IPC mechanism and things like that, and I don't see why GIO (as the GLib Input, Output and Streaming library) would need any D-Bus functionality.

I mean, if GSettings needs the GIO APIs, then we could just have a separate GSettings module which depends on GIO in the same way GIO depends on GObject... or am I wrong?

Can anyone elaborate on why these things are planned this way? Over at Xfce, we're using GIO extensively in Thunar and we are about to port other applications to GIO as well. We're also interested in D-Bus, the unique application API and GSettings, but putting all of this into GIO sounds a bit "random", and rings my personal alarm bell.
(Anonymous)
Oct. 12th, 2009 08:29 am (UTC)
multiple modules
This has been discusses several times on the gtk list and in other places. The cost of each extra library, especially a core library that are used by almost all apps, is very high. Each extra global (RTLD_GLOBAL) library causes an extra hash lookup for each symbol resolve (in the app and all shared libs linked to it). It also causes slowdown on startup due to more linker work and i/o seeks.

Additionally, its not always so simple to split core functionallity like that and not get circular dependencies. For instance, GSettings will likely need i/o apis, but if we make it a module that depends on the i/o module then the i/o code can't use settings (which is useful for e.g. setting the default handlers for uri schemes, etc).

So, its been decided the gio means basically "glib interfaces and objects" and is a general module for lowlevel non-ui APIs.
(Anonymous)
Oct. 13th, 2009 02:38 pm (UTC)
Re: multiple modules
Sorry, I must have missed those earlier discussions. Anyway, I'll read up on that to refresh my mind. But first, my reply:

Is the symbol lookup overhead a real concern? I can imagine the same slowdown occurs with GDK, cairo, pango and all the other shared libraries (including GLib and GTK+) we usually link our applications to.
I know modularity can be both bliss and pain. Personally, I lean towards seeing it as a positive goal as it helps to develop/release components independently and also supports experimenting with different ideas without affecting everything else directly. But I guess you know all these advantages and disadvantages of modular software design yourselves...

(BTW, does the growing number of independent D-Bus services ring a bell? People seem to *want* modular design. Why go the opposite direction when developing libraries?)

> Additionally, its not always so simple to split core functionallity like that and not
> get circular dependencies. For instance, GSettings will likely need i/o apis, but if we make
> it a module that depends on the i/o module then the i/o code can't use settings (which is useful
> for e.g. setting the default handlers for uri schemes, etc).

Of course it can. GSettings could ship a GIO extension if it absolutely needs to. I could be wrong here, but isn't GSettings intended to be a per-application settings interface (e.g. no global schemas information) rather than a provider of standardized options like URI handlers? I'd rather expect desktops/applications to ship their own GIO extensions for adding URI handlers (e.g. via the corresponding GNOME or Xfce settings options for preferred apps) than to have this in GSettings itself.

Maybe there's a better example for why GIO would also need GSettings?

> So, its been decided the gio means basically "glib interfaces and objects" and is a general
> module for lowlevel non-ui APIs.

Yeah, it looks like my understanding of the purpose of GIO is not up to date. Bummer.
(Anonymous)
Oct. 13th, 2009 04:30 pm (UTC)
Re: multiple modules
The per symbol lookup costs is a real concern yes. The long link lists we have in gnome is a real concern which is why we work hard to get the last deprecated lib out.

Having some level of modularity is of course nice, but shipping lots of small libraries in the same tarball just hurts performance for no large advantage (since they come from the same module there isn't much advantage to the splitting up).

GSettings is similar to GConf in that there can be global defaults for any setting, as long as something ships a schemas file for it. There is no reason it cannot be used for something more than only app-specific settings.

Having each user of the lib install their own (conflicting) extensions for each possible setting in glib when we already (will) ship a settings system doesn't seem right.
ext_209896
Oct. 13th, 2009 08:26 pm (UTC)
Re: multiple modules
> The per symbol lookup costs is a real concern yes. The long link lists we have in gnome is
> a real concern which is why we work hard to get the last deprecated lib out.

Ok. I don't doubt this concern, but is there some blog post or anything backing this up with actual numbers?

> Having some level of modularity is of course nice, but shipping lots of small libraries
> in the same tarball just hurts performance for no large advantage (since they
> come from the same module there isn't much advantage to the splitting up).

Yeah, I know, in this scenario separate shared libraries are not really the kind of "modularity" we normally talk about. I mean, app developers could still decide which module to use and which not to load though... unless GTK+ loads them all anyway (and I guess it'll indeed make use of GSettings).
I like think in separate entities if things don't necessarily belong together (which is why I'm usually skeptical about decisions to move things together) but I can also see why all those Python people come to me and tell me that they love how their standard library ships everything they need.

> GSettings is similar to GConf in that there can be global defaults for any setting,
> as long as something ships a schemas file for it. There is no reason it cannot be used
> for something more than only app-specific settings.

Any chance we can work together on this to define some basic set of standard desktop schemas? Would be cool.

> Having each user of the lib install their own (conflicting) extensions for each
> possible setting in glib when we already (will) ship a settings system doesn't seem right.

Yeah, I know. GIO doesn't prioritize its extensions and it probably wouldn't make much sense anyway.
(Anonymous)
Oct. 13th, 2009 02:26 pm (UTC)
Thanks
Thanks for the overview Jason! Very useful and interesting questions and conclusion. Thanks Ryan for doing dconf and gsettings.
( 6 comments — Leave a comment )

Profile

color, uphair, smile
jasondclinton
Jason D. Clinton

Latest Month

September 2011
S M T W T F S
    123
45678910
11121314151617
18192021222324
252627282930 

Tags

Page Summary

Powered by LiveJournal.com
Designed by Tiffany Chow