Waqas Hussain пишет:
On Fri, Jun 18, 2010 at 5:00 PM, Konstantin Kozlov <[email protected]> wrote:
Well. According to my experience, based on knowledge of my behavior and
behavior of my friends, the fact that my message is not "new" anymore on
the other side is enough to assume that user on the other side read it.
See XEP-0085: Chat State Notifications. That nicely solves the problem
of determining if the other side is paying attention to the
conversation.
No. We don't know how messages represented on the other side. It
could be chat windows, pop-ups or whatever author of the application can
imagine. So, in some implementations some (or all) chat state
notifications are meaningless or has limited usability.
Also, analyzing chat state of the other side trying to guess if the
user paid attention to your message is much less convenient than just
receive <read /> notification.
As for me, running chat application is for chatting. For reading and
writing messages. I can't image a guy who just ignores messages from
contacts in his contact list, just confirming without even reading them. At
If you can't imagine that, then you clearly aren't trying.
Believe me, I really did.
least neither me nor any of my friends behave that way. What is he running
his IM application for? If he don't want to read message from the specific
contact, he can just put it into hist ignore list, and he will never receive
any confirmation message. But, once again, confirming reading of the message
without reading it actually sounds strange for me.
Not all conversations are equal. Much of it is background chatter, or
messages which don't actually require a response. It's quite
convenient following such conversations in a background window, or
through popups (toasts).
So, what?
I absolutely wouldn't want to have to
manually indicate my having read every message I receive.
If there are some people, who doing so, that's the problem of those
people. Why other people should suffer because of them? Let's give to other
people such ability, 'cause in the most cases it will be really useful.
XEP-0184: Message Receipts solves a very specific problem for me: It
lets me know my message got through, and wasn't swallowed by a network
issue or server crash. All clients implementing the XEP do let me be
sure of this. Changing this existing behavior would awkward, error
prone, and of limited utility: i.e., very unwelcome.
A lot of people are on wireless networks, or have otherwise turbulent
connections, or have servers which crash. This isn't a rare problem at
all. Your useful ability can be achieved through other means
(XEP-0085: Chat State Notifications). Don't force the rest of us to
suffer please.
Your response sounds like either you didn't read my previous
messages at all, or just didn't understood the idea.
The idea is:
1. You don't "have to manually indicate your having read every message
you receive". As I said before, most of the clients already marking just
arrived messages as "new", to tell user, that he has unread messages.
Then somehow they decide that user read the message, the message marked
as "read". That (already existing) mechanism is supposed to be used to
send that <read /> confirmation. So, you don't have to do manually. In
fact, as a recipient of the message, you won't notice any changes at all!
2. Adding <read /> element to the XEP won't change existing behavior at
all. If either of clients do not support <read /> element, it won't
notice anything. It will just process <received /> notification and
following <read /> notification either will not be sent or will be
ignored. If both of them are supporting new XEP, then after receiving
<received /> notification, you'll get <read /> notification just after
message on the other side will be marked as "read".
Now, tell me, how this extension of the original behavior can break it,
making "awkward, error prone, and of limited utility"? Or how it can
make suffer anyone?
