Encountered this morning -- list operation had unfulfilled emails
waiting for network operations but folder normalization determined
they were missing and used a writebehind to remove them from the
operation, but the loop to remove them explodes (can't do a remove
within a foreach). This loop solves that problem.
Two problems: (a) determination for vector expansion was not accounting
for INCLUDING_ID flag properly, and (b) messages added to the interior of
the vector during normalization (can happen when the database has a
gap in the middle of the vector) were being treated as appended (i.e. new)
messages, causing the ConversationMonitor to load all of them.
Forgot to deal with situation where a message in the remote folder
is removed that isn't stored in the local database. In that case,
the local position will be <= 0 and should be treated as a NOP
(although still signal that the total remote_count has changed).
Rather than attempt to be selective, there's enough changed here that we might as well
blow away the search index and let the indexer start afresh. Future tweaks to the
search index might need to be more selective.
Fixes a couple of performance problems (slow sorting of Contacts
being added one at a time, and multiple GtkEntryCompletions being
created when New Message is used) as well as broke out
ContactListStore so one could be created and used for the three
GtkEntryCompletions needed in the window.
Better document structure handling. Now dealing with all portions of a
MIME document, not just the first, and properly inserting inline images
into the final HTML view.
With earlier implementation, it was possible for the "email-completed"
signal to be fired for emails that were already locally complete
(in particular, when flags were being updated). This ensure the
signal is fired once and only once.
Mass email creation is taking far longer than it should (since the
vector expansion causing it isn't writing email bodies or headers,
merely inserting a row into two tables and writing small metadata to
one of them). This patch breaks up vector expansion more than before
and turns off SYNCHRONOUS mode.
Although these fixes don't close the above ticket, they do alleviate many of its
symptoms and generally seems to improve the experience. It also fixes a couple
of nasty bugs in vector expansion and account synchronization.
This simplifies the various Folder implementations, removes one (large)
replay queue operation, makes vector expansion _much_ simpler, and
generally makes the Geary API a bit cleaner.
Because the code affected included some of the proposed fixes for
operation. That plus the vector expansion changes may have some
affect on that ticket.
The recent fix to support dotstuffing (#7173) introduced a regression
where it was possible for incomplete SMTP buffers (i.e. the message)
to be delivered.
The SMTP layer now deals in Memory.Buffer objects, which required
some small changes to the Authentication interface. Also, some
missing error-handling in RFC822.Message was introduced.
a couple of assertions in the code could cause a similar problem, so this removes
them and replaces them with log messages. Later code in the code path deals with
this problem in a more sane manner.
More specifically, I believe the IMAP rework deals with the problems of certain
servers returning the preview information out-of-order and in separate server data
lines properly.
I had mistakenly used == to compare FolderPaths, which have their own
equal_to method.
Also, this cleans up a bit of the ConversationSet logic that wasn't
needed since EmailIdentifiers take folder_path into account in their
hash and equal_to methods.
The prior ImapEngine.EmailPrefetcher pulled messages one at a time to
prevent hogging the connection with lots of data (when a lot of new mail is
detected). This patch simplifies some of the preparation code and
pulls the mail down in 128K batches, meaning multiple small messages are
pulled at once, meaning quicker availability without blocking the connection
entirely.
This accomplishes a few things:
* Adds some signals to the Account that aggregate various Folder
signals, so anyone can find out when mail has been appended to any
folder, for example.
* Refactors the ConversationMonitor further. The conversation grouping
logic has been split out into a ConversationSet, and
ConversationMonitor proper is now just the folder interaction.
* The new ConversationSet tracks duplicate emails better using
Message-IDs, so if you get an email in multiple folders we can figure
out whether we should actually add it as a new email or not.
* Using all of that, we now kick off a full-conversations update
whenever new mail comes in on any folder, so your conversations update
as you're looking at them when Geary sees new mail, regardless of
folder.
