The first one splits timeouts for command writing and response reading, which I think is more robust, because timeout is effectively restarted after successful write operation.
The second one hopefully fixes https://github.com/deltachat/deltachat-core-rust/issues/1383 for real. Previously custom timeout was applied to all operations except the most expensive one: sending the data and waiting for response. Even worse, after #26 the default timeout (30 seconds in delta chat) was applied to reading the message into the buffer, sending the message, and waiting for response. As a result, sometimes after writing the whole file, 30 seconds were already elapsed, and QUIT was sent immediately after the message instead of waiting for response. Now I have applied the correct timeout and split writing and reading timeouts, like in the first commit.
Commit messages explain the same thing, but without references to delta chat issues and github PRs.
A follow-up for #26
Two commits.
The first one splits timeouts for command writing and response reading, which I think is more robust, because timeout is effectively restarted after successful write operation.
The second one hopefully fixes https://github.com/deltachat/deltachat-core-rust/issues/1383 for real. Previously custom timeout was applied to all operations except the most expensive one: sending the data and waiting for response. Even worse, after #26 the default timeout (30 seconds in delta chat) was applied to reading the message into the buffer, sending the message, and waiting for response. As a result, sometimes after writing the whole file, 30 seconds were already elapsed, and QUIT was sent immediately after the message instead of waiting for response. Now I have applied the correct timeout and split writing and reading timeouts, like in the first commit.
Commit messages explain the same thing, but without references to delta chat issues and github PRs.