[Bug 300655] Message transmission delay with ICQ
George Kiagiadakis
kiagiadakis.george at gmail.com
Tue Jul 17 10:09:24 BST 2012
https://bugs.kde.org/show_bug.cgi?id=300655
George Kiagiadakis <kiagiadakis.george at gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |kiagiadakis.george at gmail.co
| |m
--- Comment #15 from George Kiagiadakis <kiagiadakis.george at gmail.com> ---
Imho, I believe this is a networking/server issue. I've seen the code of
empathy and the respective tp-qt and text-ui code and I don't see anything
being done differently. I would love it if someone can provide dbus traffic
logs with bustle of a conversation that got completely screwed with delays.
Btw, this "bug" may actually be 2 bugs. I remember somebody recently did a
screenshot of an ICQ conversation where messages were re-ordered and some of
them omitted in the text-ui, while the other side showed them correctly. This
is one bug, I believe a CM one.
There is the other thing though that sometimes happen even with XMPP. You type
a message, hit enter, then nothing happens for a while. After a couple of
seconds or even minutes, you see the message that you typed. I sometimes
experience this with facebook and google talk when my network connection is not
very stable. If I open the web interface immediately and see what happens on
the server, I notice that my message has not been sent indeed. If at some point
the text-ui shows the message, then after a small delay, it appears on the
server as well.
What happens here is that every message has in fact 3 different states and we
only handle one of them.
- State 1: You type a message and send it to the CM. Message has been sent to
the CM, but not to the network.
- State 2: The CM acknowledges by emitting the MessageSent signal. This only
happens when the CM has successfully sent the message to the network and this
is the point where we show it in the text UI. Any initial delay that you may
see from the point that the message was typed to the point that the message was
shown is because the CM isn't able to send it to the network.
- State 3: On protocols that support it, the CM signals a "delivery report"
message when the server acknowledges that the other person(s) have received the
message. This is when the message actually appears on the fb/gtalk web
interface.
It would probably be less confusing for the users if we handled all 3 states
properly. Step 1, send the message to the CM and show it in the text UI with
some indication that it hasn't been sent yet. When the CM signals MessageSent,
remove the indication or replace it with some "awaiting delivery" indication if
the protocol supports delivery reports. When the delivery report comes, remove
the indication or replace it with a warning icon if delivery failed. IIRC,
kopete did something similar and so does skype and so does the N9 chat ui
(which actually uses telepathy; if you have one, take a careful look).
--
You are receiving this mail because:
You are the assignee for the bug.
More information about the Kde-telepathy-bugs
mailing list