On Sunday, 11 August 2013 14:00:57 CEST, Thomas Lübking wrote:
Googles "threading" substitute.
I'm in favor of this feature. I'm not sure whether I'll have time &
motivation for implementing it myself, though. If it gets implemented,
there's a couple of requirements which I'd like it to satisfy:
a) No cost for non-gmail accounts
b) Doing the "right thing" IMAP-wise
c) Integrating well into Trojita's code and UI
I'll start with the IMAP-specific bits. I've asked [1] about how they
implement this, in particular about the immutability of this data and
whether they consider a "regular" THREAD=... command. The answer [2] was
that clients should be able to cache the thread-id using the normal IMAP
rules, i.e. it gets invalidated on UIDVALIDITY change, never else. There
are no plans to convert this into a regular THREAD command, unfortunately.
This is a combination of good and bad news. The bad news is that this is
going to require a lot of code which is special-cased for GMail (which we
cannot afford to ignore, unfortunately), and that certain situations like
"joining threads" is not available. The good news is that due to it being
FETCH-based, new message arrivals will actually be very
bandwidth-efficient.
What I think is needed, from the backend POV, is:
- Upon first threading request when the gmail threading is available (and
none of the usual threading appears to be supported), fetch the thread ID
for each and every message in a mailbox which is missing it
- When the result is available, it shall be used by the
ThreadingMsgListModel to build the threading, similarly to how the existing
threading data are handled
- However, I'm against simply extending the TreeItemMessage (and the
corresponding sqlite table) with a quint64 gmailThreadId -- I don't want
users of other systems to pay the price here. Another sqlite table will be
needed, and the gmail threading should be managed in a data structure at
the level of TreeItemMsgList, IMHO.
It requires X-GM-EXT-1 CAPABILITY, implementation could be like
a "Show Conversation" button in the header widget and on
clicked() fire a new thread to "uid fetch <uid> (X-GM-THRID)"
and on response trigger "uid search X-GM-THRID
<64_bit_thread_id_here>" (by setting the search text to
":=X-GM-THRID <64_bit_thread_id_here>" ?!?)
That's also possible, but would IMHO suck from the usability POV. What I'd
like to have is, instead, having this fully integrated as another threading
method. I.e. View -> Show messages in threads etc.
I'm uncertain about the temporary hack you describe. It *could* work, but
IMHO it's still a lot of work which goes in a wrong direction.
Finally, the ThreadingMsgListModel is in dire need of refactoring. While
I'm still convinced that having searching, sorting and threading all
handled in a single model is good (and, in fact, required due to Qt's MVC
architecture). but the current implementation could use some love for the
interaction between searching and threading, and also local, flag-based
searching shall be added (see Shanti Bouchez' mails from earlier this
year). That said, I hope that this refactoring can happen parallel to any
work on gmail's threading -- just be prepared to some (manageable) merge
conflicts. I'm saying this mainly in a hope that someone would read through
ThreadingMsgListModel's source and do the refactoring for me :).
With kind regards,
Jan
[1] http://www.ietf.org/mail-archive/web/imapext/current/msg04894.html
[2] http://www.ietf.org/mail-archive/web/imapext/current/msg04897.html
--
Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/
