> On 2 Dec 2016, at 13:00, Christian Schudt <[email protected]> wrote: > > Can't XEP-0333 used for that? > > A sends a message to B with a "read request". > B reads the message and sends a "read receipt" back to A. > > The read receipt is stored in the server archive normally as any other (chat) > message. > > Clients can query the archive in a normal way, e.g. all message from "today", > e.g. receive 3 chat messages and 2 read receipts and therefore know, that > there's one "new", unread message. > > I probably don't understand your point though…
I think you possibly don’t :) This is for synchronising the ‘read’ status between all of my clients, such that a) they’re consistent and b) when a new client comes online it can quickly determine which contacts have unread messages. /K > > -- Christian > > Gesendet: Freitag, 02. Dezember 2016 um 12:44 Uhr > Von: "Kevin Smith" <[email protected]> > An: "XMPP Standards" <[email protected]> > Betreff: [Standards] Unread syncing > 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). > > 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: [email protected] > _______________________________________________ > _______________________________________________ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: [email protected] > _______________________________________________ _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
