GNOME Bugzilla – Bug 677953
user-accounts: Set high DBus timeouts for managing realms
Last modified: 2012-06-14 09:48:00 UTC
Got some DBus timeout errors. All calls to realmd should have high timeouts, since discovering or enrolling can take forever. User can cancel, so this isn't a usability issue.
Created attachment 216212 [details] [review] user-accounts: Set high DBus timeouts for managing realms Enrolling the machine, or discovering realms can take a long time. We don't want DBus timeouts.
Review of attachment 216212 [details] [review]: Why do you need both of these ? Shouldn't it be enough to specify the default timeout at creation time ?
Because they're different proxies. The realm manager, and then the various realms.
I really don't like this. I think this means that you're using the wrong API.
That's an old preconception, and the timeout limit was fixed years ago in dbus-daemon years ago. Modern DBus APIs can block. I've designed DBus APIs the 'old' way before, and if they're even minimally complex things get horribly messy. I really don't want to do that again with realmd. It's really a shame that a decade of hard to use DBus APIs have been written to simulate awkward, incomplete, semi-stateful-when-they-shouldn't-be, untested asyncness over dbus, when dbus itself provides asyncness. Even cancellation can be done with blocking DBus methods, by passing in a cancellation id, similar to how GCancellable works. See PolicyKit's CheckAuthorization and CancelAuthorization methods: http://hal.freedesktop.org/docs/polkit/eggdbus-interface-org.freedesktop.PolicyKit1.Authority.html#eggdbus-method-org.freedesktop.PolicyKit1.Authority.CheckAuthorization
Yeah, it's 100% fine to have D-Bus methods that take a long time to complete - and most of the time it's even preferred since it makes the API significantly easier to use. E.g. just having Foo() is a lot easier than FooStart() and a ::FooCompleted signal, not only in apps but also for gdbus(1) / d-feet usage. As another example to comment 5, you can also use something like the Job object pattern http://udisks.freedesktop.org/docs/latest/gdbus-org.freedesktop.UDisks2.Job.html http://udisks.freedesktop.org/docs/latest/ref-dbus-jobs.html to convey progress and allow cancellation (if you want programmatic control, you put the cancellation_id passed in the invoker method as a property on the Job interface). For example, in GNOME Disks these objects are used to render spinners, see http://people.freedesktop.org/~david/palimpest2-spinners.png
Fine with me then. I'm running on old D-Bus knowledge here.
The GLib API docs might need some tweaking: "This is useful for long-running operations that takes longer than the default timeout (which is a on the order of magnitude of tens of seconds). For some applications, consider using a pattern where the method returns once the operation is underway (e.g. immediately) and emits a signal when the operation terminates (though beware of leaking information with/in the signal return value)."
We generally need a "best practices" document for D-Bus APIs - another popular topic that comes to mind are D-Bus properties: when to use them, when they should be writable, when they shouldn't and why.... and even though this is not really GLib-specific, I think the path of least resistance is to add this to the GIO docs (then we can even recommend what C/GObject types to use and so on).
Hey, I know just the right person to write that document :-)
Review of attachment 216212 [details] [review]: I guess comment 7 means: go ahead