[Kde-pim] KIMAP2

[Christian Mollekopf]

Hey,

On Saturday 18 June 2016 10.29:23 Daniel Vrátil wrote:
> 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 ;-)

...we'll see ;-)
The only problem I guess is the design of the parser that just blocks until it 
has read all it needs instead of just reacting to whatever data comes in.
But once reading really is asynchronous I see 0 point in a thread to read from 
a socket.

> 
> > * Support for QRESYNC. An extension for quick resynchronization.
> 
> +1. I'd like to see this in KIMAP1 as well
> 

While of course entirely possible, I have to ask why you'd want to backport 
that? If you need new features you should move to KIMAP2 really.

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

Optional dependencies come at a cost too, and once packaged they are usually 
not optional.
Of course I see the benefit in having the integration, so perhaps there is a 
better way for this problem.

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

Good point, something we should look into. 

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

Except that you need like 10% of the code to achieve the same... but yeah, we 
can have this as a bolt on for now ;-)

Cheers,
Christian
_______________________________________________
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/