Closed Syndace closed 5 years ago
I decided to go with the following: The encryptMessage always does a dry run first, without the user having to specify that in any way. If this internal dry run succeeds, the encryption is proceeded as normal. If the dry run fails, a collective exception is raised, which contains a list of problems that occurred. The user then has the chance to fix these issues and try again. If the user encounters an unfixable problem, for example denied trust, the user has to explicitly pass the jid+device id tuple to the encryptMessage call, which will then ignore problems with that specific tuple. This should make things more clear and explicit, while not increasing the usage complexity.
Got a lot of valuable feedback for that. First of all the callback for problems during encryption is confusing and should be replaced by some different technique. Might want to create an additional API method for the dry run, instead of using a dry_run flag, to keep the types cleaner. Might want to return a list of problems at least for dry runs. Also consider always actually throwing exceptions instead of letting a part of it succeed. The dev would then have to manually remove device ids that have unfixable problems.