diff options
author | Kitsune Ral <Kitsune-Ral@users.sf.net> | 2016-09-14 09:49:53 +0900 |
---|---|---|
committer | Kitsune Ral <Kitsune-Ral@users.sf.net> | 2016-09-16 23:28:14 +0900 |
commit | e2b19b832907325ea7580d3f3ad4679e473dbbea (patch) | |
tree | 25ad3e2a543de417823f841427e9f9fb9eb6a4cb /events/receiptevent.cpp | |
parent | 53a941afe548be49585aadda336c0e4c05ff3ff1 (diff) | |
download | libquotient-e2b19b832907325ea7580d3f3ad4679e473dbbea.tar.gz libquotient-e2b19b832907325ea7580d3f3ad4679e473dbbea.zip |
Room: change the way messages are ordered
This replaces the one-by-one timestamp-ordering algorithm of adding new
messages with copying the whole group of just-arrived messages to either
the beginning or the end of the timeline.
Since origin timestamps do not provide a reasonable order,
findInsertionPos() is entirely deleted. processMessageEvent() is
replaced by two functions: addNewMessageEvents() appends at
messageEvents.end() while addHistoricalMessageEvents() inserts them at
messageEvents.begin(). There's no official way to insert messages in the
middle; cases when getPreviousContent() is called in parallel or a
RoomMessagesJob runs on a gap somewhere in the middle of the timeline
weren't considered before this commit and aren't considered in it.
The new ordering requires you to understand where you have got your
events from (or rather, where you want to insert them). In particular,
updateData() that processes /sync results uses addNewMessageEvents();
getPreviousContent() calls addHistoricalMessageEvents().
In order to notify clients, a single newMessages() signal gives way to
3 new signals: 2 aboutToAdd*Messages() and a common addedMessages().
In addition, clients can derive from Room and use doAdd*Messages()
virtual functions to alter/extend the behaviour.
Diffstat (limited to 'events/receiptevent.cpp')
0 files changed, 0 insertions, 0 deletions