When the machine is under heavy load and I'm moving between messages with
inline images (that are already downloaded and are in the cache) I get warnings
that GFileInfo object is not valid. I managed to get these warnings when the task
was already cancelled (I already moved to another message) but for the active task
as well. So try to access the GFileInfo object just when we know that it is valid.
Mails with many images (remote content in general) could block GTask's
thread pool for a long time, making starve other requests. Adding our
own thread pool avoids such job starving.
It wasn't checked whether the passed-in URI was correct, but the message
object returned from soup_message_new() was dereferenced anyway, which
could cause a crash.
A simple Evolution run and move between all views means creation of
more than 100 GSettings objects, with only a bit more than 10 schemas.
Reusing the objects should have a positive impact on a performance too.
When creating a temporary SoupSession, synchronize its GProxyResolver
with the SoupRequest's SoupSession which is already configured to use
our built-in proxy ESource.
This makes the code free of Coverity scan issues.
It is sometimes quite pedantic and expects/suggests some
coding habits, thus certain changes may look weird, but for a good
thing, I hope. The code is also tagged with Coverity scan
suppressions, to keep the code as is and hide the warning too.
Also note that Coverity treats g_return_if_fail(), g_assert() and
similar macros as unreliable, and it's true these can be disabled
during the compile time, thus it brings in other set of 'weird'
changes.
EShellSettings predates GSettings and is no longer necessary.
GSettings allows binding GObject properties to GSettings keys,
with optional mapping functions. That fulfills the purpose of
EShellSettings.
Exposing data members in the public struct is unwise, especially when
EMailPartList is used from multiple threads. Instead keep the members
private and provide a set of thread-safe functions to manipulate them.
Fix deadlock in EHttpRequest by running each libsoup operation in
it's own GMainContext.
The patch also replaces use of features from libsoup>=2.39, because
we can't change dependency. The code is based on code from CalDAV,
which uses synchronous libsoup API as well and works with
libsoup<2.39
Simplify the EHttpRequest by using synchronous libsoup API instead
of spawning another async operation within already asynchronous handler.
This avoids nested event loop, complex locking and makes to code much
simpler.
All mail-parsing and formatting code has been moved to em-format.
Parsing is handeled by EMailParser class, formatting by EMailFormatter.
Both classes have registry which hold extensions - simple classes
that do actual parsing and formatting. Each supported mime-type
has it's own parser and formatter extension class.
This splits the giant EMailRequest to individual EFileRequest, EStockRequest, EHTTPRequest and EMailRequest,
making the first two available globally from e-utils, the othe two are loaded only with mailer,
since no other component uses them.
Milan Crha