[patch] break glib bindings by adding timeout_milliseconds

David Zeuthen david at fubar.dk
Wed Mar 1 09:23:17 PST 2006

On Wed, 2006-03-01 at 11:26 +0100, Thiago Macieira wrote:
> David Zeuthen wrote:
> >I think it comes down to whether we want to support methods that can
> >take minutes, hours, even months (for e.g. Hibernate) to return. If we
> >don't we may as well hide the concept of timeouts from the application
> >developers completely. Perhaps this is why it was omitted in the glib
> >bindings.
> I support that.
> Methods that know they will take a long time to complete its work should 
> instead use signals. The return value should be whether the call 
> succeeded or not -- e.g., the user may not be allowed to place the 
> machine in hibernation; hibernating is not available on this computer, 
> etc.

I don't think D-BUS should force the developer to what and what isn't
good API design. Suffice to say, I disagree with you - see my reply to
Dan Berrange on why this is (error handling). 

Anyway, let's not turn this into a "what is good and what is bad API
design" thread.. clearly D-BUS is so low-level that it should support
both :-)

> The rationale is very simple: if a method takes a long time to complete 
> and was called as a result of user interaction, there should be some kind 
> of indication to the user that the call was made and there should be some 
> feedback, in the form of growing progress bars or a simple "Erasing all 
> your data, please wait" dialog box with no Cancel button.

Sure, however, note that this is still possible (and even planned) even
with a method call that blocks for a long time.


More information about the dbus mailing list