It turns out that empathy-auth-client is also an observer as well as a handler. This causes trouble when empathy is co-installed with kde-telepathy. The empathy auth process works like this: * empathy-auth-client is launched as an observer * while being an observer, it checks if the account is a GOA account or if the password for this account is otherwise saved in gnome-keyring. * if either of this is true, it claims the channel and becomes a handler for it, providing the authentication details to the CM. * if none is true, it lets the channel be dispatched normally The problem of course is that when MC looks for a handler, because empathy-auth-client is already running as an observer, MC gives it a high preference and picks it up again as a handler. In ktp we should do something similar. The concept of having an observer claim a channel is called a non-interractive approver. The idea is that it is called silently before any other approvers and it can claim the channel if it believes it should do so. This way we can ensure that our auth handler is the one that is always picked for accounts that have been configured through kde-telepathy. More info: http://telepathy.freedesktop.org/spec/Client_Observer.html
I don't fully understand this. How does one switch from being an observer to a handler? What happens when "it lets the channel be dispatched normally"? Surely MC will look for an valid handlers running, and choose ours which is running rather than the empathy-auth-client which is only an observer.
(In reply to comment #1) > I don't fully understand this. > > How does one switch from being an observer to a handler? By calling Claim() in the ChannelDispatchOperation. It's explained in the spec. > What happens when "it lets the channel be dispatched normally"? > Surely MC will look for an valid handlers running, and choose ours which is > running rather than the empathy-auth-client which is only an observer. Maybe I wasn't clear on this. empathy-auth-client is both an observer and a handler. As an observer, it only checks if the channel can be handled with itself and if it can, it calls Claim() and handles it as a handler. If not, then it returns from ObserveChannels() and lets MC pick a handler, but since it is itself a handler as well (which is also running at that time), MC has high chances of using it as a handler.
I'm not sure we can do this. >The empathy auth process works like this: >* empathy-auth-client is launched as an observer >* while being an observer, it checks if the account is a GOA account or if the password for this >account is otherwise saved in gnome-keyring. We would do the following: > ktp-auth-client is launched as an observer > ktp-auth-client opens kwallet and then sits there like a like a comatosed potato whilst we display a kwallet prompt to the user doing nothing with the channel > By this point, if empathy did have the password, we've already shown a kwallet dialog.. and the connection has probably timed out. Given we can't rely on kwallet being open (and if you are on gnome, it almost certainly won't be) will this actually help solve anything?
[15:37] <gkiagia> d_ed: you're probably right about this bug