-
-
Notifications
You must be signed in to change notification settings - Fork 117
feat: pre-messages / next version of download on demand #7371
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
6fe6723 to
8140ebc
Compare
2f1c383 to
6bcc795
Compare
8443b17 to
702771f
Compare
126c64f to
bb0fd7c
Compare
- Remove partial downloads (remove creation of the stub messages) (#7373) - Remove "Download maximum available until" and remove stock string `DC_STR_DOWNLOAD_AVAILABILITY` (#7369) - Send pre-message on messages with large attachments (#7410) - Pre messages can now get read receipts (#7433) Co-authored-by: Hocuri <hocuri@gmx.de>
bb0fd7c to
a98fe05
Compare
| "CREATE TABLE download_new ( | ||
| rfc724_mid TEXT NOT NULL DEFAULT '', | ||
| msg_id INTEGER NOT NULL DEFAULT 0 | ||
| ) STRICT; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@link2xt I'm wondering whether we should add UNIQUE(rfc724_mid) or UNIQUE(msg_id)? Or even both? I guess it doesn't really make sense to have the same message in there twice?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we need both msg_id and rfc724_mid in this table? rfc724_mid can be obtained from msg_id.
EDIT: Got it, msg_id is 0 when rows are inserted to download in fetch_new_msg_batch(). But UNIQUE(rfc724_mid) may still make sense.
Previously, the uid_next wasn't advanced, which didn't create any problems, but it also was inefficient, because another loop was done trying to fetch the message again (and then finally skipping it, because it's already known).
| * - `download_limit` = Messages up to this number of bytes are downloaded automatically. | ||
| * For larger messages, only the header is downloaded and a placeholder is shown. | ||
| * For messages with large attachments, two messages are sent: | ||
| * a Pre-Message containing metadata and a Post-Message containing the attachment. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"Full message" was a better term, "post-message" is literally "smth going after the message". And the full message should contain metadata as well, but the documentation doesn't say that
|
|
||
| /// Metadata contained in Pre-Message that describes the Post-Message. | ||
| #[derive(Debug, Clone, PartialEq, Serialize, Deserialize)] | ||
| pub struct PreMsgMetadata { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually this is PreMsgData, it's metadata for the "post-message" (and even not metadata, but a part thereof)
| .log_err(ctx) | ||
| .ok(); | ||
|
|
||
| download_msgs(ctx, &mut session) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it's better to move this right after download_known_post_messages_without_pre_message() so that it goes before scan_folders(). Scanning folders isn't that important, it's even debounced to once per minute.
EDIT: Before, it even preceded the whole fetch_idle().
| JOIN msgs m ON d.msg_id = m.id | ||
| WHERE m.rfc724_mid IS NOT NULL AND m.rfc724_mid != ''; | ||
| DROP TABLE download; | ||
| ALTER TABLE download_new RENAME TO download; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Consider renaming to downloads, we usually use plurals for tables
| uids_fetch.push(uid); | ||
| uid_message_ids.insert(uid, message_id); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if download_limit.is_none_or(|download_limit| size <= download_limit) {
uids_fetch.push(uid);
uid_message_ids.insert(uid, message_id);
} else {
download_later.push(message_id.clone());
largest_uid_skipped = Some(uid);
}Maybe do smth like this here? This way pre-messages should still be downloaded immediately and big emails are downloaded later to speed up downloading of pre-messages and other small messages.
I've chacked that JSON-RPC tests work with this suggestion.
The test just passes, it seems there's no need to remove it.
…imap_when_downloaded
This comment was marked as resolved.
This comment was marked as resolved.
13c8b29 to
4a119fc
Compare
…essage before There is a bug in pre-messages: - A pre-message adds an entry to the `msgs` table with the `rfc724_mid` of the post-message - If the pre-message and post-message are fetched in separate cycles: - `prefetch_should_download()` returns false, because `rfc724_mid_exists()` returns something - so, the message is not added to `download_later`, and never automatically downloaded.
…e-messages modify group members There are no partial messages anymore, so i have no idea what else to check.
4a119fc to
84ce946
Compare
|
Force-pushed the branch to have #7625 as a single commit with the description from the PR. Also fixed |
| trans.execute( | ||
| "UPDATE imap SET target=? WHERE rfc724_mid=?", | ||
| (target, msg.rfc724_mid), | ||
| (target, &msg.rfc724_mid), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This deletes the post-message on IMAP, but the pre-message is never deleted. We need to save rfc724_mid of pre-messages to the db to delete them as well. Maybe add msgs.rfc724_mid_pre column?
It currently fails because pre-messages aren't deleted on IMAP.
DC_STR_DOWNLOAD_AVAILABILITY#7369This is the branch for #7367
closes #7367
Currently removed tests
Progress of the tests
Overview about the recycled(♻️) and dropped(🗑️) tests of the tests that I removed in #7373
All the recycled tests were already recycled/re-made except for some which are still to do:
(none)
Furthermore there need to be new tests to test the downloading/scheduling changes.
TODO Tests
postponed to do tests
(none)
discarded/ignored test ideas
maybe we should reconsider / discuss those?