Dbus timeout issue

[Jacopo De Simoi]

Hi David, thanks for your prompt reply

> Hi,
> 
> On Sat, Aug 6, 2011 at 6:21 AM, Jacopo De Simoi <wilderkde at gmail.com> wrote:
> > After some discussion with Thiago (of {Qt,}DBus fame) he suggested that in the udisks api
> > the call + reply should be substituted (or better, integrated) with a call + emit signal, since there should never be
> > a call + reply if it is known that the call might take more than 1 second.
> 
> No, there is no need to make the API worse by doing this (why is it
> worse? Because then you can't easily use the API from
> gdbus(1)/dbus-send(1) or d-feet).

Well, in my implementation idea the signal would not replace the reply; 
imho it should be emitted alongside with the reply, so that 
if the call timed out you could still recover information with the signal, 
but all previous implementations would still work.
Would this still be considered as making the API worse?

> And, btw, what you are asking for is
> already there via the Job* properties on the Device interface.

This would tell me when filesystemUnmount finishes, but then 
we lose all informations about a possible error.
Indeed if the call times out, then it is probably flushing, 
hence the unmount probably succeded; so the reply should
not carry any error information. 
This however seems a bit shaky to me…

> Anyway, in this case, just set the D-Bus timeout in your call to
> infinite and things will work fine. For example, if you are using
> libdbus, it's the timeout_milliseconds parameter in
> dbus_connection_send_with_reply(), see

We are using QtDBus; I tried to propose the timeout approach, but 
the official mantainer of the udisks backend for solid 
(that is, the Qt abstraction layer which uses udisks)
doesn't quite like it. Indeed it looks more like a workaround than a proper fix.

Please let me know your final opinion about this, so that I can 
discuss with the udisks backend mantainer about it.
Thanks again
 Best 

 Jacopo