Before we were fetching the entire message body (including attachments) to get the
preview text. This patch now offers the ability to fetch a small (128 byte) preview
of the email.
Also, since this ticket is about speeding up performance, I've introduced NonblockingBatch,
which allows for multiple async operations to be executed in parallel easily. I've added
its use in a few places to speed up operations, including one that was causing the lag
in #3799, which is why this commit closes that ticket.
Static member objects are not always initialized in Vala properly, causing this soft
assertion. Now using static properties to lazily create the various flags on demand.
This incorporates much better duplicate detection in the local database, using both RFC-822 Message-ID as well as IMAP metadata (internaldate, RFC822 size) to determine if a message is already stored in the database. Very useful when a message is stored in multiple folders, or an already-downloaded message is returned to a folder it originated in (i.e. INBOX).
Also some minor fixes to listing email by EmailIdentifier which save a roundtrip to the server for certain edge cases.
Conversations now fully monitor the Folder for both additions and removals of messages.
This exposed a couple of bugs in the database code, which are fixed here as well. I also
used this opportunity to clean up some of the internal Conversations code, simplifying Node
management. #4333 will be a big boost here when implemented.
addressing.
Positional addressing is a nightmare for a lot of reasons, especially keeping positions
up-to-date as the Folder mutates. Now, positions are returned with the email but for
advisory reasons only, and do not keep up-to-date. It is expected that a client will use
positional addressing to "bootstrap" the application's data store, then use EmailIdentifier
addressing to traverse the Folder's contents.
Emails in a conversation with conflicting References paths were not being handled particularly well. This deals with them in a nicer manner.
Also, clarified the Folder.open_async() call's contract.
Prior commit did not completely fix the problem in the case where a remote folder open took
a long time. This bulletproofs the solution, but does mean that there will be some
situations where FAST messages return with EmailLocations that radically change in the near
future. As the contract allows for any changes whatsoever, this is acceptable.
This adds support for retrieving partial header and body blocks straight from the email, and
therefore support to pull the References header from a message (which, for some reason, IMAP
doesn't support or include in the FETCH ENVELOPE command). This is necessary for email conversations (#3808).
This required a change to the database schema, meaning old databases will need to be blown
away before starting.
Eric spotted a bug where messages retrieved via FAST (i.e. straight from the database) were
not assigned their proper EmailLocations, which has a lot of ramifications when more emails
are being requested.
This adds facilities to issue FETCH BODY<partial> syntax commands to IMAP server. Only
thing that is missing is the ability to specify body MIME parts, which can be added later.
(At that time we'll want to include support for the FETCH BODYSTRUCTURE command.)
This is a necessary component for threading (#3808).
The entire database module now uses Transactions in order to guarantee atomicity of all
operations. However, due to limitations in SQLHeavy and its implementation of async, we
can't use it (and SQLite's) transactional models. This patch introduces a rather hamhanded
transactional model where the entire database is locked for each request using a
NonblockingMutex. This is the safest approach, but certainly not an optimal one. When
SQLHeavy's code is in place, hopefully we can rip this out with a minimum of fuss.
