mirror of
https://github.com/chatmail/core.git
synced 2026-04-17 21:46:35 +03:00
bfae2296b7
I assume that the problem was that sometimes, alice2 or fiona doesn't
accept alice's smeared timestamp, because `calc_sort_timestamp()`
doesn't allow the timestamp of a received message to be in the future. I
tried this patch:
```diff
diff --cc src/chat.rs
index 9565437cf,9565437cf..a2e4f97d0
--- a/src/chat.rs
+++ b/src/chat.rs
@@@ -46,6 -46,6 +46,7 @@@ use crate::receive_imf::ReceivedMsg
use crate::smtp::{self, send_msg_to_smtp};
use crate::stock_str;
use crate::sync::{self, Sync::*, SyncData};
++use crate::timesmearing::MAX_SECONDS_TO_LEND_FROM_FUTURE;
use crate::tools::{
IsNoneOrEmpty, SystemTime, buf_compress, create_broadcast_secret, create_id,
create_outgoing_rfc724_mid, create_smeared_timestamp, create_smeared_timestamps, get_abs_path,
@@@ -1212,7 -1212,7 +1213,11 @@@ SELECT id, rfc724_mid, pre_rfc724_mid,
received: bool,
incoming: bool,
) -> Result<i64> {
-- let mut sort_timestamp = cmp::min(message_timestamp, smeared_time(context));
++ let mut sort_timestamp = cmp::min(
++ message_timestamp,
++ // Add MAX_SECONDS_TO_LEND_FROM_FUTURE in order to allow other senders to do timesmearing, too:
++ smeared_time(context) + MAX_SECONDS_TO_LEND_FROM_FUTURE,
++ );
let last_msg_time: Option<i64> = if always_sort_to_bottom {
// get newest message for this chat
```
...maybe this patch makes sense anyways, but you still get the problem
that the message sent by alice2 (i.e. the add-fiona message) will have
an earlier timestamp than the message sent by alice, because alice
already sent more messages, and therefore has more timesmearing-seconds.
It's unsure it makes sense to modify calc_sort_timestamp() this way because if some chat member has the clock in the future (even unintentionally), their fresh messages will be sorted to the bottom relatively to others' fresh messages. Maybe it's even better to limit the message timestamp ("Date") by the current system time there.
To really fix the problem, we could send a serial number together with the timestamp, that distinguishes two messages sent in the same second. But since we haven't gotten complaints about message ordering since some time, let's just leave things as they are.
Since all this timesmearing is a bit best-effort right now, I decided to
instead just make the test more relaxed.
Delta Chat RPC python client
RPC client connects to standalone Delta Chat RPC server deltachat-rpc-server
and provides asynchronous interface to it.
rpc.start() performs a health-check RPC call to verify the server
started successfully and will raise an error if startup fails
(e.g. if the accounts directory could not be used).
Getting started
To use Delta Chat RPC client, first build a deltachat-rpc-server with cargo build -p deltachat-rpc-server
or download a prebuilt release.
Install it anywhere in your PATH.
Create a virtual environment if you don't have one already and activate it.
$ python -m venv env
$ . env/bin/activate
Install deltachat-rpc-client from source:
$ cd deltachat-rpc-client
$ pip install .
Testing
- Build
deltachat-rpc-serverwithcargo build -p deltachat-rpc-server. - Install tox
pip install -U tox - Run
CHATMAIL_DOMAIN=nine.testrun.org PATH="../target/debug:$PATH" tox.
Additional arguments to tox are passed to pytest, e.g. tox -- -s does not capture test output.
Activating current checkout of deltachat-rpc-client and -server for development
Go to root repository directory and run:
$ scripts/make-rpc-testenv.sh
$ source venv/bin/activate
Using in REPL
Setup a development environment:
$ tox --devenv env
$ . env/bin/activate
$ python
>>> from deltachat_rpc_client import *
>>> rpc = Rpc()
>>> rpc.start()
>>> dc = DeltaChat(rpc)
>>> system_info = dc.get_system_info()
>>> system_info["level"]
'awesome'
>>> rpc.close()