zinface
/
Signal-Desktop
mirror of https://github.com/signalapp/Signal-Desktop.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
Signal-Desktop/js/keychange_listener.js

29 lines
809 B
JavaScript
Raw Normal View History

Improve keychange notice reliability/perf Bind a single listener to keychange events from the storage interface, which then looks up relevant conversations and adds notices to them, with tests. Previously we would need to instantiate a conversation model in order to start listening to its key change events. In practice this usually happens at startup but we shouldn't rely on it, and it incurs higher overhead since it creates a different listener for each conversation. // FREEBIE
2017-05-08 05:18:22 +08:00
/*
* vim: ts=4:sw=4:expandtab
*/
;(function () {
'use strict';
window.Whisper = window.Whisper || {};
Whisper.KeyChangeListener = {
init: function(signalProtocolStore) {
if (!(signalProtocolStore instanceof SignalProtocolStore)) {
throw new Error('KeyChangeListener requires a SignalProtocolStore');
}
signalProtocolStore.on('keychange', function(id) {
Fetch conversations once, clean up ConversationController API (#1420) * Fetch conversations once, clean up ConversationController API Race conditions around re-fetching have caused some problems recently, so this removes the need to re-fetch conversations. They are fetched once or saved once, and that is it. All interaction goes through the ConversationController, which is the central source of truth. We have two rules for Conversations: 1. If a conversation is in the ConversationController it doesn't need to be fetched, but its initial fetch/save might be in progress. You can wait for that fetch/save with conversation.initialPromise. 2. If a conversation is not already in the ConversationController, it's not yet in the database. It needs to be added to the ConversationController and saved to the database. FREEBIE * Remove Conversation.fetch() call in Message.handleDataMessage() FREEBIE * ConversationController.API cleanup: Fix two missing spots FREEBIE
2017-09-02 00:10:41 +08:00
ConversationController.getOrCreateAndWait(id, 'private').then(function(conversation) {
Improve keychange notice reliability/perf Bind a single listener to keychange events from the storage interface, which then looks up relevant conversations and adds notices to them, with tests. Previously we would need to instantiate a conversation model in order to start listening to its key change events. In practice this usually happens at startup but we shouldn't rely on it, and it incurs higher overhead since it creates a different listener for each conversation. // FREEBIE
2017-05-08 05:18:22 +08:00
conversation.addKeyChange(id);
Fetch conversations once, clean up ConversationController API (#1420) * Fetch conversations once, clean up ConversationController API Race conditions around re-fetching have caused some problems recently, so this removes the need to re-fetch conversations. They are fetched once or saved once, and that is it. All interaction goes through the ConversationController, which is the central source of truth. We have two rules for Conversations: 1. If a conversation is in the ConversationController it doesn't need to be fetched, but its initial fetch/save might be in progress. You can wait for that fetch/save with conversation.initialPromise. 2. If a conversation is not already in the ConversationController, it's not yet in the database. It needs to be added to the ConversationController and saved to the database. FREEBIE * Remove Conversation.fetch() call in Message.handleDataMessage() FREEBIE * ConversationController.API cleanup: Fix two missing spots FREEBIE
2017-09-02 00:10:41 +08:00
ConversationController.getAllGroupsInvolvingId(id).then(function(groups) {
_.forEach(groups, function(group) {
group.addKeyChange(id);
});
Improve keychange notice reliability/perf Bind a single listener to keychange events from the storage interface, which then looks up relevant conversations and adds notices to them, with tests. Previously we would need to instantiate a conversation model in order to start listening to its key change events. In practice this usually happens at startup but we shouldn't rely on it, and it incurs higher overhead since it creates a different listener for each conversation. // FREEBIE
2017-05-08 05:18:22 +08:00
});
});
});
}
};
}());