[Telepathy] Acknowledging Messages in an Observer

[Guillaume Desmottes]

Le vendredi 10 février 2012 à 13:37 +0000, Simon McVittie a écrit :
> On 09/02/12 17:06, Guillaume Desmottes wrote:
> > Actually the Shell does ack messages even when it's an Observer (but
> > only if user interacts with the chat bubble by expanding the toaster
> > notification (yes, that's its true name) or manually opened the chat
> > bubble).
> 
> I think it should at least only do that if the channel has been handled
> *by someone*, to avoid Observer loggers losing the messages. For that
> particular use of only-Handlers-acknowledge, it'd be OK to acknowledge
> if it isn't a Handler but has been one in the past, because that means
> *someone* is the Handler, so Observers have already had their chance.
> Acknowledging in an Approver would not defeat that either, I don't think.

That's actually what's happening with incoming text channels. The Shell,
as an Approver, claims the channel for itself and handles it. So if at
some point it's not the handler any more that means that either it
redirected it itself (DelegateChannels()) or Empathy re-requested it
with  the 'delegate to preferred handler' hint; in any case the channel
has a handler (and will be closed by MC if it stops having one).

For outgoing channels, I guess that in theory there is a race if:
- Alice request a channel to Bob
- The Shell observes the channel
- Bob send's a message to Alice
- The Shell acks the channel
- The Logger observes the channel

But it's a pretty rare case and I had never been reported as being an
issue as in most case the first message on the channel is sent by the
handler who requested the channel (Empathy).

> Neither of those avoids the race described below, though...
> 
> You could Claim and delegate, perhaps? Claim will block until observers
> are happy, so if you only acknowledge after you've Claimed, everything
> is OK.
> 
> > If not Empathy would claim that some messages are unread while they
> > actually are. Empathy watches the PendingMessagesRemoved signal and so
> > won't ack an already acked message.
> 
> How do you avoid the race condition where Empathy and Shell acknowledge
> at the same time, the winner of the race succeeds, and the loser sees
> PendingMessagesRemoved followed by a failed method reply?

In theory, yes that's how it would happen. In practice it's very
unlikely as the Shell only acks when user interacted with the
notification or chat bubble. And this notification is slightly delayed
to give a chance to Empathy to display and ack the message first (this
is how we fixed the 'I'm actively chatting in Empathy and the Shell
popups message while I'm reading them in Empathy' bug).
As Empathy only ack message when user focused its tab, user should have
to be really quick (or D-Bus *really* slow) to interact with the Shell
and then with Empathy without it noticing the acking first.


I agree it's all very complex and hacky but that's the best solution we
came up with. All of this makes me think that the "one handler" model
doesn't really fit for text channels, which is why we discussed some
other crazy approach (the logger as the handler, etc) during our TP
session at hackfest.




	G.