On Fri, Jun 18, 2010 at 11:20 PM, Konstantin Kozlov <yag...@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. >>> At >>> >> >> 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 >>> 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? 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. -- Waqas Hussain
