Progress feedback and cancellation of long-running method calls.

[Simon McVittie]

On Tue, 28 Jun 2011 at 14:20:54 +0100, David Woodhouse wrote:
> The problem is on the *client* side. That's using dbus-glib too, but
> there seems to be no way to find the serial number that was used for a
> given call that we made with dbus_g_proxy_begin_call(). 

The serial number is generally considered to be a low-level detail (part of
the message-passing layer, not the object model), but if it'd be useful,
I wouldn't say no to some better API for it.

> (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?)

They're extensible, but only by the D-Bus Specification. I believe libdbus
copes with new message types (although I could be wrong), but the reference
dbus-daemon (which is sometimes a security boundary) does not allow them.

In practice, introducing non-backwards-compatible protocol features like this
is a major pain - it took a long time to get Unix FD passing, and "maybe"
types still haven't landed, for the same reason. It's possible, but awkward.

On Tue, 28 Jun 2011 at 10:23:03 -0400, David Zeuthen wrote:
> 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.
[...]
> [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

Telepathy does a similar thing with ChannelRequest objects, but we require
an extra round-trip to call Proceed() after setting up the match rule.
Using directed signals to avoid this is a nice idea, we should consider it
for future Telepathy versions.

(Another way to solve this race would be to use a NO_REPLY method call on a
caller-supplied object instead of the rarely-used feature of directed signals,
but I agree that this is a fine use-case for directed signals.)

    S