Re: [Telepathy] Acknowledging Messages in an Observer
Le jeudi 09 février 2012 à 19:24 +, David Edmundson a écrit : 1) Is it up to the client code to throw away its references to the text channel after it successfully delegates? Yes, the client is supposed to update HandledChannels if the DelegateChannels() call succeeded. See delegate_channels_cb in telepathy-glib/base-client.c 2) Can the client keep the channel, but know to effectively act like an observer? If so is there any way to find out if a channel is being handled by our application or not? Sure you can do that. The Shell does exactly that actually (but still ack messages when needed, as said in my other mail). I added tp_base_client_is_handling_channel() is tp-glib to easily know if we are currently the handler of a channel or not. I ask because after I call delegateChannels when I browse my original handler in dbusviewer Client.Handler/HandledChannels still seems to have the original channel. This seems wrong? Also when I delegateChannels can I pass hints? In the process of this contact list - plasmoid - textUI approach any hints now get lost. We use a special KDE channel hint to work round a kwin bug, and now that's not working. It seems limiting to not be able to pass them. No, this has been considered when designing the API but we didn't support it. See https://bugs.freedesktop.org/show_bug.cgi?id=25293 for the full story. Thanks for all your help so far! Np :) G. ___ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] Acknowledging Messages in an Observer
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. 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? S ___ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] Acknowledging Messages in an Observer
Le vendredi 10 février 2012 à 13:37 +, 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. ___ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] Acknowledging Messages in an Observer
Le mercredi 08 février 2012 à 17:09 +, Simon McVittie a écrit : Not acknowledging messages unless you're a Handler has (at least) two functions; I think there may have been more that I've forgotten. 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). 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. G. ___ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] Acknowledging Messages in an Observer
On 08/02/12 14:00, David Edmundson wrote: Currently (mostly thanks to a lack of delegateChannel in TpQt) this plasmoid purely an observer with our main handler running in a window elsewhere. ... So in short; in this particular case is it ok for an observer to ack messages? I think it is, but I don't want to go against the spec, particularly something in capital letters. If not how does Gnome-Shell handle this? It's a Handler, and so is Empathy, and the Shell delegates the channel to Empathy when necessary. Sorry, I think you do want delegation support in telepathy-qt - patches welcome if it isn't implemented already! (If in doubt, base it on what telepathy-glib does, which has been verified to work in Shell.) When you double-click a contact in the Empathy contact list, Empathy calls EnsureChannel with the org.freedesktop.Telepathy.ChannelRequest.DelegateToPreferredHandler=TRUE hint, and itself as the PreferredHandler; if the Shell happens to be handling a channel to that contact already, it gets HandleChannels re-invoked, notices the hint and responds by delegating the channel to Empathy. If nobody is handling the channel (i.e. it's new), it's Empathy that gets HandleChannels called on it, in which case it does not try to delegate the channel to itself :-) When you double-click a conversation bubble in Shell, Shell also delegates the channel to Empathy, this time without a request from Empathy. When we discussed this in the context of GNOME Shell, we came to the conclusion that having more than one Handler, and having the active Handler for the Channel follow where the user should be looking if they want to keep up with it, was sufficiently useful to pay the (complexity) price of DelegateChannel. For instance, one thing that you get by having exactly one Handler at a time, which acknowledges the messages, is that either Empathy or Shell notifies you (makes a sound or gives the window manager an attention request or pops up a bubble or whatever) when there's a new incoming message, but never both. (This approach also means that Empathy doesn't necessarily get run at all, for quick conversations done entirely in gnome-shell.) Not acknowledging messages unless you're a Handler has (at least) two functions; I think there may have been more that I've forgotten. The main one is that it avoids Observers missing messages. An Observer like telepathy-logger is expected to connect to signals, download state, *then* reply to ObserveChannels. HandleChannels isn't called until all Observers have done this; so if you don't start acknowledging until you have had HandleChannels called on you, you're guaranteed not to delete any messages before the logger has seen them (unless it's unreasonably slow and MC gave up waiting for it, in which case, get a better logger). If you start acknowledging straight away in an Observer, there's no guarantee that you won't ack a message before the logger (another, equal, Observer) has had a chance to record it, and it'll be lost forever. A secondary function is that it avoids getting errors back from AcknowledgeMessages when you give a message ID that someone else already acknowledged, and having to try again, acknowledging messages one-by-one and ignoring the errors, in order to ack them all! We were using this acknowledged message system as a way to keep track of the unread messages in both the main chat handler and the plasmoid and show/remove the correct notifications in the two places. That's entirely reasonable... but it might turn out to be a lot simpler to say that whoever is currently the active Handler (for a given Channel) is expected to notify about it. S ___ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
