[Standards] XEP-0184: <received/> vs. <displayed/> vs. <read/>
waqas20 at gmail.com
Fri Jun 18 20:09:04 UTC 2010
On Fri, Jun 18, 2010 at 11:20 PM, Konstantin Kozlov <yagiza at yandex.ru> wrote:
> 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.
My mistake. I assumed you were agreeing with Kev. You were suggesting
a new <read/> element be added to message receipts?
As Yann Leboulanger noted, <active/> does what you think <read/>
should do. See http://xmpp.org/extensions/xep-0085.html#definitions
>>> 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.
>> If you can't imagine that, then you clearly aren't trying.
> Believe me, I really did.
You mustn't get a lot of messages then. I can get swamped by messages
at times. Most of them don't require/expect a response. Also, I'm not
always paying attention to the screen, or to the IM client. When you
have multiple items requiring focus, some get higher priority than
others. That's not unreasonable.
>>> least neither me nor any of my friends behave that way. What is he
>>> his IM application for? If he don't want to read message from the
>>> contact, he can just put it into hist ignore list, and he will never
>>> any confirmation message. But, once again, confirming reading of the
>>> 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?
So, I don't want to take action to mark those as read immediately, and
I don't want the other side to assume that I'm not reading. I am
reading them. Just don't want to alt-tab when a response doesn't need
to be written.
> Your response sounds like either you didn't read my previous messages at
> all, or just didn't understood the idea.
Yes, as noted above. <active/> does what you want.
> 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!
I do. Clients mark as "read" on focus. That can happen unintentionally
(quickly switching tabs via keyboard). This can sometimes not happen
when it should (reading, but without the window/tab focused).
> 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?
Yes, as noted above: <active/> does what you want.
More information about the Standards