On Thursday, 17 October 2013 19:02:21 CEST, Kevin Krammer wrote:
It's common to have sent mail in some other mailbox -> the mapping
cannot
be done without fully reconstructing it on the client side, and that
needs
fetching fetching a subset of headers from each and every message.
That's
expensive.
Or using local header caches which leads to trolls claiming the program
is
"bloated".
Trojita already caches these headers locally; that's not a problem. The key
difference is that Trojita does not have to load them *at all* for most of
the messages now.
If a mailbox has, say, 50k messages, Trojita will *not* load their headers
or envelopes or anything [1]; these data are only loaded for the messages
which are visible on screen [2]. This works extremely well in practice, but
it also has a major drawback: we cannot thread when the server doesn't
support the THREAD extension, so there's no threading on GMail. They have
their own proprietary extension and we might add support for it at some
point in future, but it's not here just yet.
In my book, the speed difference wins big time -- just try opening a huge
mailbox in Trojita and in your favorite mail client of choice and see the
difference.
the MIIME tree parser needs to be designed in a way that it allows
asynchronous completion of parts, because decryption might incur user
interaction (typing passphrase), keyserver communication, etc.
Is the KDE's MIME parser reasonably Qt-only, or does it depend on KDE's
utility classes? So far, Trojita relied on the server-side IMAP parsing, so
adding support for GPG is not "just" a matter of throwing a validator in.
I don't mind designing and implementing the auxiliary structure myself, but
having a standalone MIME parser would reduce the effort quite a bit. To me,
the adaptor between $whatever-data-are-returned-by-the-parser and the MVC
API expected by Trojita looks much simpler than a full-blown MIME parser.
That said, I've always wanted to brush up my boost::spirit skills, so it
might even be a fun project in the end.
Cheers,
Jan
[1] Anything but UID and FLAGS, which are arguably needed for various
reasons that I explained in my thesis. These are, of course, also cached,
and on decent IMAP servers it means almost no traffic on each mailbox sync.
[2] There's a configurable preload to make sure that we don't hit network
on every mouse wheel move, etc.
--
Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/
