GNOME Bugzilla – Bug 274142
Limiting the number of in-a-row fetched messages
Last modified: 2021-05-19 11:31:32 UTC
When there are a lot (more than 100) messages without download, or there are too big messages in the server, it would be very interesting having an option for defining the number of messages downloaded (or the size of downloaded messages) before "consolidating" (that is, showing them in the corresponding folders and removing them from server). My idea is acting as fetchmail "limit" option, when fetching POP3 messages from a server. Optionally, after consolidating, Evolution could go on with getting the remaining messages, acting transparently for the user. Is this a bad idea?
this is covered by another bug, 'incremental download' or something like that. it is quite difficult to implement because of the way update events are handled (that stupid update freeze stuff), and the ui can cause signfiicant performance overheads too.
Yes, the "incremental-download" bug (#1718) could be related to this, but I don't think that "consolidating" the interface after (for example) 50 downloaded messages, or 3 Mbytes of downloaded messages, could cause a significant performance overhead. The user has been waiting for these messages to download (sometimes more than 3 minutes, if he/she hasn't broadband access)... In this case, the bottleneck is in the slow retrieving of messages, and allowing users to read new messages after a given number/size of downloaded messages could be a good idea. And Evo could make the most of this time, and delete the already-downloaded messages from server too.
"but I don't think that "consolidating" the interface after (for example) 50 downloaded messages, or 3 Mbytes of downloaded messages, could cause a significant performance overhead." Have you tried? Actually - I have. And yes it does cause a significant performance over head. So no, currently this is not practical.
For IMAP this would be possible since 3.4 due to http://developer.gnome.org/camel/3.4/CamelFolder.html#CamelFetchType
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/Community/GettingInTouch/BugReportingGuidelines and create a new enhancement request ticket at https://gitlab.gnome.org/GNOME/evolution/-/issues/ Thank you for your understanding and your help.