[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.
David
More information about the dbus
mailing list