olabini
commented
5 years ago OK, after thinking through this, my proposal is that we move towards a structure that looks like this:
- We have a new type, prekey_manager_s
- The otrng_client_s has one prekey_manager_s that will always exist
- Inside of prekey_manager_s we have a list of mappings from domains (or something) to the server identity for that domain. This list will be empty initially
- The manager also has a variable prekey_client_account that is of type prekey_client_s
- The manager also has a list of prekey_client_s instances called prekey_client_peers
- The fundamental idea is that we use the prekey_client_account for things related to our own account. This always exists and is responsible for publishing etc
- The prekey_client_peers list only has clients in it when a request is "in flight". So we create one on the fly, and then destroy it when we are done with looking up ensembles for a specific peer.
- The information about prekey servers is stored directly in the manager, separately from the prekey clients themselves, so we can keep this information
Inside the plugin, I propose that we separate out the prekey plugin functionality into two different sub-plugins. One for managing everything related to the account (checking storage, publishing), and another for getting ensembles for peers. I think this will clean up a lot of stuff.
Thoughts, comments?
claucece
We need to rethink completely how the prekey communication happens - the current model is not workable at all - especially the use of contexts on the callback object. I'll need to map all this functionality and figure out how to change it to something that works.