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

List:       kmail-devel
Subject:    Re: imap jobs page
From:       Bo Thorsen <bo () sonofthor ! dk>
Date:       2003-05-07 14:51:05
[Download RAW message or body]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Monday 05 May 2003 20:07, Carsten Burghardt wrote:
> Am Montag, 5. Mai 2003 12:02 schrieb Till Adam:
> > > BTW: If the people working on IMAP (and thankfully we now have more
> > > than one of them) would first merge the dIMAP with online IMAP
> > > code, stuff will become a lot easier in the middle to long run for
> > > them.
> >
> > Ok. What excatly do you mean by "merge" ? Simply give up online imap
> > in favour of dIMAP? Share more code? Port online imap to maildir and
> > do a bit of caching when a message is donwloaded anyhow? Sorry if
> > this has been discussed before, but I don't have a clear picture of
> > what you envision.
>
> The ideal solution would be to have an imap implementation that is
> (more or less) independant from the storage. This way you could enable
> more or less local caching: none at all (which is normal imap), on a
> per folder basis or complete (wich is our current dImap). But I do
> consider this a lot of work and not realistic for 3.2.

I have thought about this a bit, and there are a couple of problems with 
it. A simple example is the X-UID header, that must be stripped for all 
adds. Of course this could just be done for all folder types.

Another problem is that we have a two-way map between idx and UID that 
would need to be kept in sync. Another thing we need to add at one point 
is to have a map from iCalendar UID to idx, because for the IMAP resource 
we search for the mail with a given iCal UID all the time. (Sorry, but 
both iCalendar and IMAP use the term UID, and they're *not* the same.)

> So the question is what we _can_ do for the next release that acts like
> a milestone for the "final target". I must admit that I haven´t thought
> about this yet. One reason is that I had the fealing that dImap is not
> really used and might be buggy. Therefore it would result in a lot of
> work to merge the two implementations.

I also tend to think of dIMAP as a bit untested - though kroupware_branch 
has been - and will continue to be - quite well tested. /me needs a 
server that can have reasonable sized disks for setting up my own IMAP 
server.

> I´m not sure which of our current accounts is the better basis. There
> have been some bugs in the imap code but it´s also a lot better now and
> is fast enough to work with it. The dImap code is developed for the 1.0
> release of kroupware and is therefore definitely not really fast. We
> have bugreports from people who think that it´s damn slow.
> BTW: we already share a lot of code. Think about imapaccountbase.

Okay, several issues here:

Speed - online IMAP will *always* feel faster, because the work is 
distributed over the time you use it, whereas dIMAP does all it's work in 
one go. That said, there are incredible amounts of optimizations possible 
for dIMAP, and I hope it will get a lot faster later. I do disagree with 
the ones that say it's damn slow - My very limited test case with ~ ten 
folders and ~ 5 mails per folder performed syncs in about ten seconds, 
more if a lot of uploading was happening. Uploads really are slow though.

Code sharing - There's not really a lot to do about this, since the dIMAP 
have been reduced to being just the sync code plus some code to handle 
the map/X-UID problems I mentioned above. All other code is simply the 
maildir implementation. As you say, the account code is well shared. The 
dIMAP account code is ~ 200 loc.

Future basis - what I want is to make the implementation of different 
cache strategies in dIMAP (but my time is very limited) and once we have 
that, evaluate how the online IMAP compares to it. I and others have 
thought about the possibility to ditch it completely, but I'm not sure 
this is a good idea.

One idea I had was to start out with merging them usability-wise. For this 
I was thinking about making the user choose between caching or not, when 
he has an IMAP folder. If we could make it a checkbox in the account 
setup, and make it possible to switch the two accounts, the user can't 
see that it's really two different implementations he's using. This is my 
best suggestion for what should be done for 3.2 - perhaps with a warning 
that dIMAP is a new implementation, so the users could experience 
problems.

Bo.

- -- 

     Bo Thorsen                 |   Praestevejen 4
     Senior Software Engineer   |   5290 Marslev
     Klarälvdalens Datakonsult  |   Denmark
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE+uR1ZmT99lwfUS5IRAlyvAKCQ19U3vt4Cg2LgW5aSbwCdpzVMIgCfZInO
kU5V+oioyRGj2ZshrGnBN80=
=UfGp
-----END PGP SIGNATURE-----

_______________________________________________
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]