You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Nov 25, 2022. It is now read-only.
while this is working, currently, the saved bandwidth is used for re-downloading the message as soon as IMAP-IDLE wakes up to notice us about the message we've just sent.
the message is not added to the database, however, it is downloaded before aborted.
the very most of this additional bandwidth can be saved by checking the Message-ID before downloading the body. IMAP has some methods for this i cannot tell from mind :)
nb: thinking it over, this additional download was also done in the past - eg. the IMAP-upload is done to the SENT-folder and this folder - as well as all others - are scanned about every 30 minutes.
so already now, we save 1/3 compared to all versions up to now (0.20). with this optimization we will save 2/3 :)
The text was updated successfully, but these errors were encountered:
@bpiddubnyi great that you want to have a look at this :)
not directly related, but when working on the loop that downloads from the IMAP folder:
there may be a bug in it, a race condition or whatever. in the past, it happened some times that old messages get downloaded randomly, see #156. i always assumed sth. with the stored "last-id", however, i did not found anything (hard to find errors on code written by oneself :)
however, might also be that the bug is removed by the code removal/changing of https://github.com/deltachat/deltachat-core/milestone/2
Another related possibility to skip downloading the message body and to reduce the mobile traffic are subject-only messages #437 and attachments #436 .
due to #370 of https://github.com/deltachat/deltachat-core/milestone/2 , we save about half of the sending bandwidth by uploading a copy using "bcc" instead of a separater IMAP-upload.
while this is working, currently, the saved bandwidth is used for re-downloading the message as soon as IMAP-IDLE wakes up to notice us about the message we've just sent.
the message is not added to the database, however, it is downloaded before aborted.
the very most of this additional bandwidth can be saved by checking the Message-ID before downloading the body. IMAP has some methods for this i cannot tell from mind :)
nb: thinking it over, this additional download was also done in the past - eg. the IMAP-upload is done to the SENT-folder and this folder - as well as all others - are scanned about every 30 minutes.
so already now, we save 1/3 compared to all versions up to now (0.20). with this optimization we will save 2/3 :)
The text was updated successfully, but these errors were encountered: