[Kde-pim] Moving Trojitá to extragear

[Jan Kundrát]

On Friday, 23 November 2012 14:08:14 CEST, Kevin Krammer wrote:
> I was wondering if you could check if anything you have is missing from 
> respective KDEPIM libraries, e.g. IMAP commands not in kimap.

Dear Kevin,
I suspect that the architecture of KIMAP is very different from how Trojitá works. Trojitá doesn't use KIO at all, it has something called ImapTask which is -- I suspect -- similar to some extent, yet slightly different. I don't expect it would be possible to directly use something like QRESYNC from Trojitá and put it into KIMAP, or vice versa. If you have any concrete ideas, I'm all ears, it's just that I don't really see a possibility to share the IMAP code or even test cases directly. (Trojitá does use some low-level bits from KIMAP, like the modified-utf7 decoder.)

What Trojitá's IMAP code does provide is an interface based on Qt's QAbstractItemModel which presents a tree of the whole remote IMAP server. The data is passed around via custom data roles and the API is more or less read-only. Modifications are performed through explicit funtcions like these:

 void markMessagesRead(const QModelIndexList &messages, const FlagsOperation marked);

 void copyMoveMessages(TreeItemMailbox *sourceMbox, const QString &destMboxName, QList<uint> uids, const CopyMoveOperation op);

As you can see, this R/W "API" is pretty inconsistent and leaks the underlying abstraction quite a bit (using raw pointers instead of QModelIndexes, awww, no UIDVALIDITY checking, yuck, and using strings as mailbox names vs. something else for other data -- boo!). Frankly, there's nothing even resembling a stable read-write API at this point. This is something which can be improved -- and patches are welcome.

For a little bit of context, I started Trojitá back in 2006 for many reasons, and my unhappiness with KMail was one of them. I realize that your current IMAP implementation is very different from past KMail's and also from that of Mailody -- but back in 2006, I understood from some bug reports that your then-current architecture built around KIO was rather limiting, preventing even basic features like IDLE. Given that situation, I decided that starting from scratch would be better use of my time, and Trojitá is how it ended up today :).

> As with other KDE libraries, the intent is to have those available as KDE 
> frameworks at some point, i.e. with clear and minimal dependencies for 
> consumtion as Qt-addon libraries.

I have always wanted to have a *single*, stable, lightweight and well-tested implementation of RFC2045 encoding/decoding and similar stuff. When I took a look at KMIME's RFC2047 encoder/decoder, it felt like it combined knowledge of specific headers (i.e. parsing rules for From which are different than these for Subjects, etc.) with actual RFC2047 encoded-word decoding. I acknowledge that it makes sense, but that's not how I wanted Trojitá to behave, so I ended up more or less reimplementing that from scratch, with just tiny pieces of Qt's Messaging Framework being used.

That's a waste of time and I'd love to collaborate on that, but from how the code of other projects looks like, I guess that the idea of a class doing RFC2047 decoding/encoding and *nothing else* is not particularly appealing to them. And as time is limited, I haven't pursued this idea further.

Other similar tasks where I'd love to use an existing self-contained library are bits like format=flowed parsing and processing, handling TLS key pinning and plenty of stuff like that.

> This is already happening to some extend, e.g. BetterInbox.com 
> is using KIMAP, 
> KMime and has contributed KSmtp [1].
> While they still needed some kind of minimal kdelibs 
> replacement to fill the 
> dependencies, this should become unnecessary in the future.

The SMTP implementation in Trojitá is something which is in dire need of replacement. There are many options on how to proceed, and if KSmtp is reasonably stand-alone, I'll be happy to use it. At a quick glance, it uses KJob which appears to be completely standalone, at least based on its public header. Thanks for that tip, I'll keep an eye on KSmtp when I get around to solving the SMTP issues in Trojitá.

Cheers,
Jan
_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/