GNOME Bugzilla – Bug 216927
IMAP rewrite.
Last modified: 2011-04-11 11:49:51 UTC
IMAP has issues. Scalability of cache/expiry Heavy use of in-memory objects Codebase complexity/maintainability Locking complexity/maintainability Performance/pipelining of requsts Easiest fixed by a new codebase.
So should I mark bugs like bug 216738 as depending on this one?
*** bug 202529 has been marked as a duplicate of this bug. ***
*** bug 220831 has been marked as a duplicate of this bug. ***
I'm going to use this to track a lot of imap related bugs, even if they might not all be best served by an imap rewrite. Just to keep track of whats out there more easily.
*** bug 221872 has been marked as a duplicate of this bug. ***
*** bug 210163 has been marked as a duplicate of this bug. ***
*** bug 211714 has been marked as a duplicate of this bug. ***
*** bug 216414 has been marked as a duplicate of this bug. ***
*** bug 218159 has been marked as a duplicate of this bug. ***
*** bug 216607 has been marked as a duplicate of this bug. ***
*** bug 224351 has been marked as a duplicate of this bug. ***
I would like to add that I'm seeing the "BAD: Command line too long" problem when trying to apply filters to any number of messages (one, some or all) from an IMAP inbox, with Evolution 1.0.5. With 1.0.2 I never saw this (upgraded yesterday). The inbox currently has ~1.600 messages, but I successfully applied filters to 12.000 messages yesterday. Now this happens consistently and regardless of what message(s) I select for filtering. So I simply cannot filter anymore. Commenting here since the "command line too long" bug was marked as a duplicate of this.
*** bug 225073 has been marked as a duplicate of this bug. ***
*** bug 219339 has been marked as a duplicate of this bug. ***
Just for info, i've been working on the rewrite in my spare time. - completely new modular engine to execute and interpret IMAP commands - '1-copy' parsing, of almost unlimited sized results - literals handled transparently by engine, no need to do anything special with using code Current status - camel-store is partially written, non-ssl connects, login and sasl authentication mechanisms - code to parse 80-90% of possible IMAP replies - multiple outstanding requests possible Still need - write the last few reply parsers - work out how to schedule multiple 'conflicting' requests - handle folder selection - work out how to get untagged response data to their intended command and/or folder - work out what to do with namespaces - probably require camel api changes (but useful for other stores too). - implement rest of store, all of folder, summary, etc. - use cache and 'disconnected' mode
*** bug 226773 has been marked as a duplicate of this bug. ***
*** bug 227545 has been marked as a duplicate of this bug. ***
*** bug 227990 has been marked as a duplicate of this bug. ***
What's the status of this? Will it be in 1.2? And will it also deal with the various inefficiencies with IMAP accounts, in particular that it seems to re-download all message summaries after a lost connection? PS: Do I have to add myself to the CC field to get notified on changes to this bug?
I am not an expert at that. However, I don't think this was included in 1.2. And yes, you should add yourself to the Cc: list in order to get updates to this bug.
Please check NotZed comments from 06/06/2002
Attaching myself to the CC list. I'd be very interested how the new imap code is going. At Sun, we're looking at deploying Evolution as a standard mail client, but we have a really heavy use of IMAP on the server end. bug#229772 could also be related to the IMAP code.
*** bug 237002 has been marked as a duplicate of this bug. ***
*** bug 238763 has been marked as a duplicate of this bug. ***
What's the current status on this rewrite ?
*** bug 245417 has been marked as a duplicate of this bug. ***
Really interesting question: what's the status. Especially would be interested to see the support for the IDLE IMAP extension (there is a filled bug somewhere in bugzilla).
weird, how on earth did the subject get messed up.
Sorry for the spam :-(
my IMAP rewrite (which is being done independantly of NotZed's) is at this point completely usable for anyone that doesn't need "offline mode", which is the only feature not yet implemented (unless I'm forgetting something). you can enable it by building evolution with ./configure --enable-imap4 and then selecting the experimental "IMAP4rev1" provider in the account wizard dingus. You can use NotZed's latest code by building with ./configure --enable-imapp and selecting "IMAP Plus" as the provider in the account wizard so far my imap rewrite also fixes bug#206062, bug#222496, and bug#222499
*** bug 265879 has been marked as a duplicate of this bug. ***
*** Bug 233022 has been marked as a duplicate of this bug. ***
reassigning stuff that has been assigned to notzed. goodbye, dude. :-/
How were all these other bugs marked as duplicate (hence closed) when this original 'bug' doesn't have any detail beyond, "I think we need to re-do IMAP" ? I agree, it seems like the IMAP code could stand a good rewrite, but all those other bugs should have been marked as blockers, right? Or would that be Depends On, i.e., to be closed only after there really was a rewrite and all these reports have been re-tested?
Can this bug be closed in favor of IMAP+ (IMAPx) implementation ?
I'd say this is obsolete now, considering it was opened in 2001 and both Michael and Jeff are gone.