[Kde-pim] Moving Trojitá to extragear

[Kevin Krammer]

Hi Jan,

On Friday, 2012-11-23, Jan Kundrát wrote:
> 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.)

KIMAP doesn't use KIO either. The old implementation for IMAP access did 
(kmdepimlibs/kioslaves/imap4), but KIMAP (kdepimlibs/kimap) is a library 
without runtime dependencies.

What I was mostly concerned with was if there is any IMAP command that is not 
in KIMAP but which you would need. I.e. there should be no functional reason 
not to use KIMAP when developing a Qt program that wants to talk to an IMAP 
server.

> 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:

Is your low-level IMAP code tightly bound to that or is the model simply using 
your low-level/protocol code?

> 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 :).

Those limitations lead to the creation of a new IMAP client library 
implementation, KIMAP. While this does of course not change anything for 
Trojita, the main concern is that it should make a difference for anyone else 
creating a new IMAP accessing program.
Hence the question if there is anything missing in KIMAP that you would need 
would you start now.

> > 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.

My understanding of KMime is extremely limited, but as far as I can tell it 
already shows its age, but on the other hand is well tested through years of 
real-world usage.

> 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.

I see.

> > 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á.

Excellent :)

Cheers,
Kevin

-- 
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20121123/824d79a1/attachment.sig>
-------------- next part --------------
_______________________________________________
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/