Mission Control 5 disconnects and reconnects the account whenever properties that are not a DBusProperty are changed, in violation of telepathy-spec. This is in order to achieve an "instant apply" model. However, I believe that MC is the wrong place for this policy enforcement. Possible solutions for MC 5's use case: * Change the spec to document MC 5's behaviour, overruling my objection * (API break) make UpdateParameters return a boolean, "reconnect required", and let the client do the reconnect when it wants to - consider adding a Reconnect method too. libmcclient's method to update parameters could be patched to call Reconnect whenever necessary, keeping its C API unchanged * Add a new parameter-updating method paralleling UpdateParameters that has one of the above behaviours Discuss.
Unfortunately, there is no method to do this in libmcclient, so existing code could be depending on the current instant-apply semantics. I can easily add one and port any existing clients.
Proposed solution is to add a Reconnect method and break API on UpdateParameters by returning a boolean to indicate whether Reconnect needs calling. http://git.collabora.co.uk/?p=user/smcv/telepathy-spec-smcv.git;a=shortlog;h=refs/heads/update-parameters This requires easy patches to any existing clients. Before merging, this should be implemented on an MC branch as a proof of concept.
spec cabal says yes
grammar cabal says no, re-introduce the stray semicolon
Spec meeting approves in principle, I will update the branch to fix the grammar and get it insta-reviewed.
grr bugzilla
Account creation and UpdateParameters are now on a single branch: http://git.collabora.co.uk/?p=user/smcv/telepathy-spec-smcv.git;a=shortlog;h=refs/heads/account We shouldn't merge these until they both have implementations in an MC branch.
Here are some thoughts about the UI for this that we'll probably have on the GNOME desktop, since this motivates the API. The current plan, I think, is to save the new settings immediately, but display a banner with a reconnect button: /!\ Some of these changes will not take effect until you reconnect this account. [ Reconnect now ] The D-Bus API proposed above can support this. Another possibility would be to display some sort of symbol or highlight visually matching the banner, on each input widget whose setting hasn't yet taken effect: Account [ smcv@example.com ] Password [ ***** ] [x] Override automatic server/port selection /!\ Server [ jabber.vpn.example.com ] /!\ Port [ 4321 ] ---- /!\ The indicated changes will not take effect until you reconnect this account. [ Reconnect now ] This would require that UpdateParameters() returned a list of parameters (D-Bus: 'as') whose update will be delayed until the next reconnection. I think if we're breaking API anyway, we should consider breaking it in a maximally helpful way :-)
Approved in principle by sjoerd/cassidy/wjt, spec wording to follow.
Fixed in 0.17.24
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.