[Bug 26752] Setting a not supported presence state to a telepathy account does not deliver any failing feedback

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=26752

--- Comment #2 from Andre Moreira Magalhaes <andrunko at gmail.com> 2010-04-19 15:35:21 PDT ---
(In reply to comment #1)
> Sjoerd, Simon and I discussed this issue today. We agreed that this issue would
> be solved by adding a method to Account like Simon described in that chat log:
> 
> method RequestPresence ( (uss): Simple_Presence )
>                      → ( (uss): Simple_Presence )
> 
> That is: rather than calling Set('...Account', 'RequestedPresence', status),
> the UI would call RequestPresence(status), which would return successfully with
> the status that was actually set. So in the case described in the bug where the
> status can't be changed as requested, it would return the previous, unchanged
> status. If the account's not online, it would not return until the account has
> been brought online or an error has occurred in doing so.
> 
> This needs writing up as a proper spec. addition, and then implementing in MC
> and TpQt4.

I was thinking about this today and I see some problems with this solution:
1 - There is no way to know why the change actually failed (NetworkError,
UnsupportedStatus, ...).
2 - There is no point in returning the same previous presence as the user
already has this information, either cached (tp-qt4 for example caches the
current presence) or using Get('...Account', 'CurrentPresence')
3 - What if it takes too long to return? Some bindings may not be able to set
the timeout to ~infinite. QtDBus didn't have this until 4.5 and I haven't
tested this support so far.
4 - Let's imagine you have 2 applets (one sitting in your desktop and another
one in the system tray) showing the current presence. User tries to change the
presence, both applets should be in sync (blink for example) until the presence
is changed. This can't be achieved with the proposed solution.

I can think of 2 solutions for this based on the issues above

1 - Ignoring issue #3 and #4
    Add a method RequestPresence(Status) that would return nothing and raise an
error on failure.

    RequestPresence(Status) -> nothing
    Errors: Define possible errors here

    It would return successfully when the requested status is actually set, or
raise an error if something failed.

2 - Add 2 new signals:

    1 - CurrentPresenceChangeRequested(status)
    Emitted when Set("...Account", "RequestedPresence", status) is called. It
will indicate that someone is trying to change the presence to "status".

    2 - CurrentPresenceChangeFailed(errorName, errorMessage)
    Emitted if Set("...Account", "RequestedPresence", status) fails.

    If the user tries to set the requested presence with different statuses N
consecutive times and the change didn't happened or failed yet, emit
CurrentPresenceChangeRequested N times and emit
AccountPropertyChanged({CurrentPresence, status}) or
CurrentPresenceChangeFailed only once when the change occurs or all attempts
fail.

    This way separate UIs will be able to be in sync with what is actually
happening, trying to set a requested presence is in progress, failed or
succeeded.

    Use cases:
    1 - App A calls Set("...Account", "RequestedPresence", status)
    2 - CurrentPresenceChangeRequested(status) is emitted (all UIs start
blinking the icon or whatever)
    3 - Change succeeded and AccountPropertyChanged({"CurrentPresence",
status}) is emitted (all UIs update stop blinking the icon and update the
status)

    1 - App A calls Set("...Account", "RequestedPresence", status)
    2 - CurrentPresenceChangeRequested(status) is emitted (all UIs start
blinking the icon or whatever)
    3 - Change failed and CurrentPresenceChangeFailed(UnsupportedStatus,
"Status not supported by this Account") is emitted (all UIs stop blinking the
icon and update the status to CurrentPresence)

Please let me know what do you think.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.