Progress feedback and cancellation of long-running method calls.

[David Zeuthen]

Hey,

On Tue, Jun 28, 2011 at 9:20 AM, David Woodhouse <dwmw2 at infradead.org> wrote:
> I looked briefly at converting to GDBus, but g_dbus_connection_call()
> doesn't seem to give me any way to find the serial number of the
> underlying call that it made *either*.

g_dbus_connection_call() is just a thin wrapper on top of
g_dbus_connection_send_message() that does give you the serial number
if that helps

 http://developer.gnome.org/gio/unstable/GDBusConnection.html#g-dbus-connection-send-message

> I'm probably going to fall back to just generating *another* client-side
> ID for each request, included in the parameters of the method call.
> Which makes me unhappy because we already *have* a client-generated ID
> for each request: the DBus serial number.

This is what I ended up doing in PolicyKit, see the cancellation_id parameter

 http://hal.freedesktop.org/docs/polkit/eggdbus-interface-org.freedesktop.PolicyKit1.Authority.html#eggdbus-method-org.freedesktop.PolicyKit1.Authority.CheckAuthorization

and the CancelCheckAuthorization() method

 http://hal.freedesktop.org/docs/polkit/eggdbus-interface-org.freedesktop.PolicyKit1.Authority.html#eggdbus-method-org.freedesktop.PolicyKit1.Authority.CancelCheckAuthorization

> (It would be really nice if there were real DBus message types for
> progress and cancellation of method calls too, fwiw. Those are
> extensible to allow new message types, right?)

I think it would be much cleaner to just define standard D-Bus
interfaces for this (just like we the std interfaces
org.fd.DBus.Properties and .ObjectManager) instead of inventing new
D-Bus message types - the latter would include modifying every D-Bus
implementation in existence (which would probably require a major
protocol version bump since I guess it would break existing clients),
the former wouldn't.

FWIW, for udisks2, the plan is to use this kind of interface

 http://people.freedesktop.org/~david/udisks2-20110628/gdbus-org.freedesktop.UDisks2.Job.html

and export job objects. It's not really used anywhere _yet_ but the
idea is that a method that is potentially long-running returns an
object path to the created job object:

 FormatVolume(OUT o job);

and returns immediately [1]. The caller can then track progress and
wait for the ::Completed signal and check the result of the operation.

Additionally, the implementation might export other, _richer_,
interfaces on the job object path to convey more detailed information
about progress. Finally, long after an operation is started, you could
start, say, a GUI application that can list all jobs and, in the case
of udisks/palimpsest, paint e.g. a GtkProgressBar widget next to the
volume that is currently being formatted or whatever. Stuff like that.

Maybe we could have something like org.fd.DBus.Job so we can implement
common code in the various D-Bus implementations (I'd volunteer to do
the work for GDBus). In particular, for GDBus/GIO, I'd probably put
something like

 http://people.freedesktop.org/~david/udisks2-20110628/UDisksDaemon.html#udisks-daemon-launch-spawned-job
 http://people.freedesktop.org/~david/udisks2-20110628/UDisksDaemon.html#udisks-daemon-launch-threaded-job

into the library which, I think, could be useful in many D-Bus services.

    David


[1] : The obvious race of the job ending too soon is fixed by using
directed signals so the caller won't have to set up match rules. Bug
37890 is related to this, especially comment 11:
https://bugs.freedesktop.org/show_bug.cgi?id=37890#c11