Hello; > I don't think its realistic to expect a user to hit a button to confirm that > they've read the message.
Defiantly not in the sense of a regular IM usage model. I was more thinking about business applications that would use XMPP as the protocol, that this would indeed make sense. A trader, a business process, even sending a PIN code to be sure somebody got that. I think even a client can implement such things if the protocol does not have a facility. But, having the logic on the server side makes more sense, because of the issues I mentioned about multiple clients, and potentially other connectivity issues to have the mechanism centralized. I still see "delivered" as a good thing. As you mentioned, iMessage and others have this, and it has some value if that client can deal with it. iMessage however does indeed have issues, for example when you have multiple iOS clients and a laptop sitting behind the same NAT I have seen behaviors that indicate they get confused on focus. Let us hope XMPP would be better….. But email does have this concept of server side management, with flags. I would not want a client to mark all my emails "read" because I was using the laptop 5 seconds ago. In that usage model, "opening the letter" makes a lot of sense, and the client tells the server, for example, over IMAP to set the read flag. Having such a facility would or could have value. But I did not mean to have it supersede "delivered" features, or force some user to click "read" each time because the IM model is quite different than email. > If you were going to do this, you're probably better off just having that > confirmation button send an actual chat message to the person saying "I've > read your message." This way you don't even have to build anything net new. > > Most clients that implement read status do so based on simple activation the > conversation. This is consistent across iMessage, BBM, and most email > clients. As I said above we do this at my firm using a pubsub message to keep > multiple client sessions in sync in terms of whats been read. This could > easily be extended to notify the sender of the message. Regards, Jon
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ JDev mailing list Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: [email protected] _______________________________________________
