e20d8b9679
In order to optimize performance, we fold the 1st and 2nd pass of our sync strategy into one. They were essentially doing the same thing: uploading a message to the other side. The only difference was that in one case we have a negative UID locally, and in the other case, we have a positive one already. This saves some time, as we don't have to run through that function on IMAP servers anyway (they always have positive UIDs), and 2nd were we stalling further copying until phase 1 was finished. So uploading a single new message would prevent us from starting to copy existing regular messages. Signed-off-by: Sebastian Spaeth <Sebastian@SSpaeth.de> Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
40 lines
806 B
ReStructuredText
40 lines
806 B
ReStructuredText
=========
|
|
ChangeLog
|
|
=========
|
|
|
|
Users should ignore this content: **it is draft**.
|
|
|
|
Contributors should add entries here in the following section, on top of the
|
|
others.
|
|
|
|
`WIP (coming releases)`
|
|
=======================
|
|
|
|
New Features
|
|
------------
|
|
|
|
Changes
|
|
-------
|
|
|
|
* Reduced our sync logic from 4 passes to 3 passes (integrating upload of
|
|
"new" and "existing" messages into one function). This should result in a
|
|
slight speedup.
|
|
|
|
Bug Fixes
|
|
---------
|
|
|
|
|
|
Pending for the next major release
|
|
==================================
|
|
|
|
* UIs get shorter and nicer names. (API changing)
|
|
* Implement IDLE feature. (delayed until next major release)
|
|
|
|
|
|
Stalled
|
|
=======
|
|
|
|
* Learn Sqlite support.
|
|
Stalled: it would need to learn the ability to choose between the current
|
|
format and SQL to help testing the long term.
|