Kevin Smith wrote:
On Wed, Jun 16, 2010 at 8:10 PM, Konstantin Kozlov <[email protected]> wrote:
Yes. Let's sort out what means "received", "displayed" and "read" to
decide which of them are needed and which are not.
Yes.
So:
What's the use case for needing to know when the user's client has
received the message?
If sender wants to be sure, that client on the other side received
and processed the message. So, the sender is sure that once the user on
the other side will pay attention to its client application, he'll be
able to read the message.
If delivery of all the previous messages were confirmed by the <received
/> reply and THIS one was not, the sender may assume, that the message
was lost somehow and may try to resend it (if he wants).
What's the use case for needing to know when the user has been shown
the message?
I don't know. For me knowing that message was displayed on the other
side is absolutely useless.
What's the use case for when the user must have read the message?
(and noting as above that the last two are probably as close to
synonymous as you'll get in a reasonable UI).
No. If we have reasonable UI, the last one is far from synonymous to
the previous one. The last one means, that UI somehow assumed that user
read the message, so the message changed its state from "new" to "read"
one. On the most clients message don't marked as "read" automatically
when it's displayed.
For example, in Psi the message becomes "read" when it's displayed
in the chat window and the chat window is active (has input focus).
In Bombus the message becomes "read" when appropriate chat is
current screen and user confirms the message by moving joystick or
clicking button or tapping the touchscreen. Each movement/click/tap
marks only one message as read!
In the application I'm developing right now, the message could be
displayed either as a pop-up balloon or as a record in the message list
of a chat screen. So, there are 2 different ways to mark the message as
"read". By clicking "Ok" button on the screen displaying the balloon
with a message, or by highlighting it with a cursor in the message list!
Anyway, reasonable UI marks message as "read", when it has a reason
to assume that user payed attention to the message.
For me, knowing, that user on the other side read the message is
very useful. 'cause if I got <received /> confirmation from the other
side, but getting no <read /> confirmation from the other side for a
long time, I'll assume that user didn't noticed notification of my
message arrival. So, I'll try to attract his attention, for example,
using XEP-0224 (Attention). <http://xmpp.org/extensions/xep-0224.html>
Then we can start to work out what needs to be included.
Ok. Let's start.
