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.
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.
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.
message (email), suitable for decoding a message off the wire or converting a
human-generated form into something suitable for pushing on the wire via SMTP.
This bug was exacerbated by rapidly switching between folders. This patch introduces a
Cancellable to most of the requests the client performs so it can cancel old requests when
the user switches folders. This fixed some issues but exposed others.
Testing this demonstrates another bug: #4233
This adds a new flag when listing messages, FAST. This indicates that the caller wants
messages that are immediately available to the Folder, avoiding a round-trip to the server
(or even disk) if possible. Not all folders will support FAST, but it can be used (as it is
now in the client) to quickly populate the message list and then initiate a connection in
the background to get the straight dope.
This commit finishes the second half of #3793 by detecting when messages have been deleted
(or moved out of) an open folder and notifying the system of the change. The nonblocking
synchronization primitives have been beefed up and may be broken out to a separate library
some day.
This commit also introduces the ReplayQueue, which replays events that occur on the server
locally. This class will probably become much more important as time goes on, perhaps used
to store user events that are replayed on the server as well.
This commit represents the first half of this ticket, as it only monitors additions (new
emails) in the folder. A second commit will follow for monitoring removals (deleted emails)
in the folder.
The commit for #3851 changed the semantics of how messages are stored in the local cache,
and not all the code was properly updated to recognize that, particularly in EngineFolder.
This patch also introduces EmailIdentifier, which allows for a mail message to be fetched by
a unique identifier rather than its position in the folder list. This is much more
efficient and less error-prone, and means that Email objects don't have to be updated if
their position changes (although there are still some questions in that area). For IMAP,
this means being able to use the message's UID.
Needed to rethink storage strategies as I researched this and realized that a true scarce database -- where the database is sparsely populated both in columns and rows -- is not feasible due to IMAP's UID rules. The strategy now means that the database rows are contiguous from the highest (newest) message to the oldest *requested by the user*. This is a better situation than having to download the UID for the entire folder.
This commit adds support for IMAP-specific properties, of which UIDValidity is crucial toward completing #3805. The additional code is to integrate these tables into the SQLite Geary backend and to make sure this information is requested from the IMAP server.
NOTE: This commit changes the database schema. Old databases will need to be blown away before running.
Fields added. However, it would be nice to use formatting to separate them from the body of the message. This is not easy with Gtk.TextView/Gtk.TextBuffer; see https://bugzilla.gnome.org/show_bug.cgi?id=59390. This may push us to move to Webkit earlier rather than later.
This ticket enables this, however IMAP properties are not yet coming up from the local database yet, so this isn't technically complete. That work will be included in the commit for #3805, which requires those properties.
This commit introduces the idea of a Personality, customizations for particular IMAP servers and services to allow the interface to configure itself for more natural use. Also, this commit has the app start in the Inbox, and an optimization was added that makes showing what's in the Inbox (at least, what's in the local cache) come up instantly.
Now supporting folder heirarchies. The client will now descend looking for subfolders. This task now opens up multiple outstanding requests to the Engine as well as exercises the database schema.
Closing this ticket opens the door to finishing #3692.
This commit introduces lazy loading of folder contents, which allows the Engine to report back email in chunks rather than all at once (which might require a round-trip to the server). This allows for the local database results to be returned to the caller right away while background I/O is occuring.
