[Kde-pim] KIMAP2

[Daniel Vrátil]

Hi,

On Thursday, June 16, 2016 5:58:19 PM CEST Christian Mollekopf wrote:
> Heya,
> 
> With KIMAP headed for frameworks as a stable imap protocol implementation,
> I'm planning to start development on KIMAP2.
> 
> Plans for KIMAP2 include:
> * Removal of the session thread. We currently have a thread per connection
> that handles reading/writing the socket and parsing the responses.
> This design seems unecessary complex, and we have crashes in that code until
> today (I have wasted weeks trying to fix it already).
> I think the design stems from times where KIMAP was directly used in the UI-
> Thread, which is not something we do nowadays anyways, so I think it should
> be unproblematic to get rid of the threading code.

This I don't completely agree with. Even if KIMAP is used just in resources, 
you still don't want the resource unnecessary blocked on read() until timeout 
whenever your connection drops... I haven't seen a crash in SessionThread in 
quite a while, so I think we finally nailed it ;-)

> * Support for QRESYNC. An extension for quick resynchronization.

+1. I'd like to see this in KIMAP1 as well

> * Get rid of KTcpSocket, which currently adds a dependency to KIO.
> QSslSocket should be good enough, although we'll loose the certificate
> manager, but that won't work on platforms like android anyways.

It could be an optional dependency which would enable KTcpSocket when KIO is 
present and fall back to QSslSocket otherwise. I realize you want to handle 
this in Kube independently of DE, but it would be nice if KDE folks would not 
lose the integration :)

> * Possibly minor API adjustments (like the insane multi argument callbacks
> to deliver results).

Oh yeah! 

One thing I also have somewhere down on my todo list is to have an option for 
KIMAP to return raw messages. Right now KIMAP de-serializes the message, 
passes it to the resource, resource passes it to Akonadi without even looking 
inside and Akonadi serializes it back to QBA. Being able to avoid the 
serialization could speed things up during sync.

> I thought about a KAsync::Job based API, but I think it is too early for
> that, so it will stick to the KJob based API we have right now.
> (Eventually we'll definitely want to switch though, see [0])

Yeah, I don't think KAsync is there yet for this kind of library. Since we 
have support KJobs in KAsync, you can still use it to chain KJobs in the 
resource, but there's IMO no point in exposing the KIMAP2 API as KAsync::Jobs.

Cheers,
Daniel

> Please note KIMAP2 will not become a framework until it's stabilized, and
> will be versioned according to semantic versioning.
> 
> If you have other plans or wishes for KIMAP2 yourself, please let me know.
> 
> Cheers,
> Christian
> 
> [0]https://phabricator.kde.org/diffusion/AKONADINEXT/browse/develop/examples
> /imapresource/imapserverproxy.h
> [1]https://phabricator.kde.org/diffusion/AKONADINEXT/browse/develop/example
> s/imapresource/imapserverproxy.cpp;456b850448bc306e9e1608fd1707ab9ceeb08c1e$
> 318
> 
> _______________________________________________
> 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/


-- 
Daniel Vrátil
www.dvratil.cz | dvratil at kde.org
IRC: dvratil on Freenode (#kde, #kontact, #akonadi, #fedora-kde)

GPG Key: 0x4D69557AECB13683
Fingerprint: 0ABD FA55 A4E6 BEA9 9A83 EA97 4D69 557A ECB1 3683
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20160618/98663bb8/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/