Thanks for the Feedback. I think the issue with embedding it in a message is the neither XEP-0136 or XEP-0313 store message that have no body, which a includes a last read message.
Keeping it as a separate XEP means it can be used with any Message Archiving solution. Also the auto sending of read is something I want to avoid, if they haven't read it then don't move the marker. There is a separate delivered marker for this. I appreciate that delivery receipts already exist but they have to be sent for every message that requests them and as you alluded to, how your supposed to handle them with archived messages is a bit ambiguous. One solution I thought of for duplicate message ids, is for the server to embed a timestamp based on the archive into the chat marker. Naturally if I turned this into any XEP then all of this would only be sent to clients that advertise support. Regards Spencer On Sunday, 19 May 2013 at 09:23, Lance Stout wrote: > > Any thoughts either way on my "Chat Marker" proposal? > > > So, after some pondering, there are three user experiences I can see: > > 1) The primary clients talking to each other: > > So XEP-0085 by itself should cover this, as Stefan pointed out. However, it > might leave holes because of non-instanaeous delivery. Eg, Juliet sends Romeo > a message at the same time he sends an active state message. So Juliet would > assume Romeo has read a message that he might not have actually received yet. > > If we make a new element to tie the update with a specific message > ID, then that potential hole goes away. So we can add a new > > <lastread id="1234etc" xmlns="urn:xmpp:lastread:tmp" /> > > element to outgoing messages when: > > a) The last ID sent by the other person has changed (so only send a > <lastread /> update once per change in ID) > b) If the user doesn't send a response chat within some period of time, > automatically send a <lastread /> update. Basically, give the user a chance > to respond with a message and piggyback the <lastread /> update with that > (maybe > a composing state message would suffice), but if after a few seconds the user > hasn't done something and the client is still focused and active, etc, emit a > standalone update. > > As usual, we don't send these updates when the other client doesn't advertise > support for it in disco. > > The combination of just delivery receipt and chat state might be sufficient, > but I've not been able to convince myself yet that it would properly handle > case 3 with offline messages. > > > 2) A secondary client that is online, which wishes to stay in sync: > > This is the purpose of XEP-0280 Message Carbons. So long as the delivery > receipts, > chat state notifications and the <lastread /> updates from case 1 are also > synced > via carbons, everything should be covered. > > > 3) A user has received messages while offline: > > So this is the fun one because it requires some interaction with the archives. > When requesting history, the results should note the ID where the offline > storage began, as Zash pointed out. > > Based on that, the client can send a <lastread /> update. Likewise it can > generate the delivery receipts requested in the offline messages (although, > there shouldn't actually be any since you wouldn't request receipts when > sending > to an offline JID, and XEP-0184 has a slight ambiguity with how to handle > offline > messages). > > I would suggest that standalone lastread updates should be included in > archived > history because they're required to fully resume conversation state to match > other systems like iMessage, etc. The main question at this point is where to > send the updates (if at all), particularly when the sender JID is no longer > online. > > > > In general, what makes things challenging is that message IDs are not > required to > be globally unique. The same ID could be used multiple times during the same > conversation if a user is bouncing between clients or reconnects. > > > -- Lance > _______________________________________________ > JDev mailing list > Info: http://mail.jabber.org/mailman/listinfo/jdev > Unsubscribe: jdev-unsubscr...@jabber.org > _______________________________________________ > > > > > Attachments: > - smime.p7s >
_______________________________________________ JDev mailing list Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: jdev-unsubscr...@jabber.org _______________________________________________
