DeviceKit-disks renamed to udisks (original) (raw)

David Zeuthen david at fubar.dk
Tue Dec 8 09:19:06 PST 2009

On Tue, 2009-12-08 at 09:34 +0000, Richard Hughes wrote:

2009/12/8 Jedy Wang <Jedy.Wang at sun.com>: > 1) When will the renaming happen, in one week, one month, before > gnome-2-30's release or after?

I'm not sure. I'm tempted to push the upower code into a new git repo, for clarity.

FWIW, I'm planning to just move the git repo (see bug 25444 for the project request) into a location (e.g. new name) - I don't know what your plans are, but preserving all commits seems like a useful thing.

> 2) What level of ABI stability will upower/udisks provide?

For me personally, I think the standard API / ABI guarantees of the major/minor release process. I think David is less keen to promise API and ABI stability for udisks, but that's his call.

One thing is that udisks is a bit more complicated that upower - storage is really hard to get right (especially on Linux - thanks to things like device-mapper) and I bet we won't get it right the first couple of times. So that's why we reserve the right to break ABI in a controlled manner.

FWIW, I've tried (and will continue to try) really hard to explain what the ABI-incompatible changes are - see

http://cgit.freedesktop.org/DeviceKit/DeviceKit-disks/commit/?id=2949925186f17009a3284fba5846890507645534 http://cgit.freedesktop.org/DeviceKit/DeviceKit-disks/tree/README

but I bet there's always going to be people complaining (like elsewhere in this thread) that there won't be a definite stable ABI supported forever.

I would suggest using the same approach with upower for the following reasons

o Committing to a stable ABI might seriously limit what you can do. We tried that with HAL and it didn't really work.

o Consumers of upower really shouldn't be apps - apps should consume higher-level frameworks (that are ABI stable) and said frameworks are implemented using upower. And the number of higher level frameworks should be low - say, one for each desktop stack. [1]

Realistically, though, I guess upower is pretty much complete so maybe you never need to break ABI and you can keep the version at 1.0.x forever.

My point is just that a) there's no need to paint yourself into a corner; and b) you don't need to (e.g. if regular apps directly use the upower interfaces they are probably doing it wrong). I don't know.

 David

[1] :

FWIW, this is exactly how GIO/GVfs/gnome-disk-utility/udisks work - GIO provides a stable (and slimmed down - see [2]) ABI that is useful for regular apps while gnome-disk-utility provides a nice, but unstable, ABI that is useful only for disk utility programs.

The analogy to upower here might be that you want APIs at the GLib and GTK+ level for upower-related operations that might be useful for apps - like inhibiting PM and getting a signal on resume. Things not in this API would be reading the charge level of batteries - if a regular app needs to do that, it is probably doing something wrong. This is because the desktop environment should be providing this feature.

OK, so this means that you won't be able to implement a desktop environment without using e.g. upower (or trawling through /sys) since the framework specific APIs (e.g. GLib and GTK+) are not powerful enough. But that's fine since things like the battery icon (provided by the desktop environment) isn't really a regular app - it's a single app provided by the desktop environment.

Of course, this is a blurry situation (maybe it would be useful to provide API to apps for charge level of batteries (maybe only the composite one?) - I don't know) - like any other architectural situation there's really no "right" or "wrong" here. So... take all this advice with a grain of salt.

There is however (and this is the main point) a lot of need to think about the cost of choosing what kind of features you want in a stable ABI - because once you've committed to a feature in a stable ABI you get to maintain it forever. Unless you rewrite the world, HAL-style, a couple of times every decade. And we don't want to do that.

(And this is not G* specific at all - it pretty much applies to any kind of desktop environment e.g. KDE, XFCE, E, whatever.)

[2] :

e.g. GIO only shows stuff that is "potentially interesting" to apps cf.

http://mail.gnome.org/archives/gvfs-list/2009-December/msg00001.html

More information about the devkit-devel mailing list