> On 2 Dec 2016, at 11:44, Kevin Smith <kevin.sm...@isode.com> wrote:
> 
> A question:
> 
> I’ve always assumed that we would do sync of the unread (or, rather read) 
> status of messages between contacts via private PEP and, indeed, this is the 
> approach we verbally specced at a summit a while back (which I have yet to 
> write up).

Typo: Between *clients*, not contacts. *facepalm*.

/K

> 
> I’ve been thinking about this further, in the context of how the big picture 
> looks for a server and many clients, and I’m coming to the conclusion that 
> it’s not the best approach. Yes, it avoids need for any changes on the 
> server, but I think we’re in a world (MIX, PAM, MAM) where for a modern XMPP 
> setup, we’re going to need modern XMPP servers and so as long as we don’t 
> break existing interop with older systems that’s ok.
> 
> I think that the better solution is going to be putting this into the server, 
> tied with MAM. The basic flow then is that the server injects stable IDs (the 
> ones used by MAM) into stanzas you receive. Then, whenever it likes, a client 
> can tell the server that id X for contact Y has been read. The server checks 
> that this is a newer read marker than was there, to avoid race conditions, 
> and updates its state for that contact (this then gets propagated to other 
> clients). Then when coming online a client can query this state to find not 
> only the contacts with unread messages, but also the number of unread 
> messages. It can then, whenever it wants (e.g. immediately, or when a chat 
> window is opened) query either a chunk of history (e.g. last 20 messages) or 
> all unread messages for that contact (or those contacts). I think this makes 
> the client implementation vastly simpler, the server implementation isn’t 
> complex (and is simpler than the client implementation would need to be for 
> the other approach), it avoids nasty race conditions that need fancy handling 
> otherwise, and also lets a client show useful information (the unread count 
> per contact) with less exchanged data on startup.
> 
> Thoughts?
> 
> /K
> _______________________________________________
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> _______________________________________________

_______________________________________________
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
_______________________________________________

Reply via email to