DeviceKit-disks renamed to udisks

[David Zeuthen]

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