[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kmail-devel
Subject:    Re: imap jobs page
From:       Carsten Burghardt <burghardt () kde ! org>
Date:       2003-05-07 17:14:29
[Download RAW message or body]

On Wednesday 07 May 2003 14:59, Bo Thorsen wrote:
> I have removed the tasks I don't have comments to.
>
> +        <li>Merge IMAP and disconnected IMAP</li>
>
> This is the most important of all of them. I will discuss it in another
> mail.
>
> +        <li>Optimize the imap4 kioslave (e.g. get rid of the LIST in
> parseURL)</li>
>
> Pipe dream: Ditch KIO_imap completely and write a real IMAP
> implementation. And make world peace after that.

What do you mean with "a real imap implementation"?

> +        <li>Load attachments on demand</li>
>
> This is part of a whole new configuration part, at least when talking
> about dIMAP. Ideally, I want several settings: Cache everything; cache
> mails after _date_; cache mails smaller than X; cache attachments smaller
> than X; cache nothing (which would be *very* close to the IMAP impl). And
> finally, the possibility to manually override these rules, for example by
> rightclicking on the icon for the non-cached part and set it to cached.
> And so on - the possibilities are endless.

Iīm currently developing this (Iīve removed it from the list) but I wonīt do 
caching at first. The first body part and everything that is declared as 
inline is loaded, the rest is shown as icons and loaded when you click on it.
But itīs good to see your proposal as I already thought if this would be handy 
for dIMAP too.

> +        <li>Allow the user to move IMAP folders (e.g. to a different
> account)</li>
>
> Strange, I thought I already made this possible with dIMAP, but it doesn't
> work??

I didnīt test it but if you say so...but it doesnīt work for imap yet.

> +        <li>Search also in the body</li>
>
> Works for dIMAP.

OK

> +        <li>Client side filtering</li>
>
> Works for dIMAP in kroupware_branch. Cvs ci CC'ed to kmail list. It is a
> fairly small patch.
>
> +        <li>Make it faster, faster, faster</li>
>
> Especially dIMAP is currently a bit slow. The reason for this is that
> Steffen and I did not want to do *anything* in parallel, since this would
> make it much more difficult to get stable.

I agree but that is one of the reasons why I doubt that itīs a good idea to 
drop imap and continue development with dIMAP.

-- 
Carsten Burghardt
PGP: http://www.magic-shop.de/Carsten_Burghardt.asc

_______________________________________________
KMail Developers mailing list
kmail@mail.kde.org
http://mail.kde.org/mailman/listinfo/kmail

[prev in list] [next in list] [prev in thread] [next in thread]