GNOME Bugzilla – Bug 665371
Decommission legacy IMAP backend
Last modified: 2013-01-10 10:36:27 UTC
Hi; Imapx was introducted few year sago in evolution but this is very unclear why one should choose imap over imapX or the other way-around. (I don't have an idea myself what is imapx). Some disambification should be done, for instance, in the wizard Imap and imapX should be merged in one type in the wizard, and a checkbox could add under imap selection to use imapx. The wizard process sould also explain better what is imapx. That would be more consistent, and not make imapx another protocol but rather an extension of imap (I guess the x from imapx stands for extension).
http://chenthill.wordpress.com/2010/01/11/evolution-with-improved-imap-support-imapx/ might be a starting point for the list of advantages imap+ (imapx) brings over imap.
Thanks for the link, but my point is also to improve the user experience among evolution, and I think the user account creation can be improved in this area for imap/imapx.
I recall Andre asking basically the same, to include it at least in user docs. Andre, is the description available, or we didn't make a conclusion for it yet? (I'm sorry, I do not recall many details.)
Milan: What description? As long as nobody explains which option a user should choose for which reasons, there's nothing I could write. ;-)
*** Bug 670277 has been marked as a duplicate of this bug. ***
Yup, I just vaguely recalled we had a similar chat and I thought there was an outcome from it. If there wasn't any, then no problem, blame my poor memory.
see bug 677721 comment 1 for what's left to do.
Matthew Barnes [Evolution developer] 2012-06-09 02:02:51 UTC For the record, the IMAP features lacking in IMAP+ are: - Quota support. - The ability to use non-virtual Junk and Trash folders (mainly for using Evolution in combination with web mail). - Something about picking custom envelope headers to download, mainly useful for filtering. Those are all the ones I'm aware of, anyway. None of these are real critical in my book but they do have a devoted following. Especially the second one.
*** Bug 677721 has been marked as a duplicate of this bug. ***
Feel free to add to the list: - body_Search in IMAP is done server-side (if supported by the server), while IMAPx downloads whole message folder for searching. There might be a bug report filled already for it, I guess.
Quota support: done. http://git.gnome.org/browse/evolution-data-server/commit/?id=95d730c78c4748469c50163c2d59e65fb0e1227a
Support for non-virtual Junk and Trash folders: done. http://git.gnome.org/browse/evolution-data-server/commit/?id=1fd3da8927177ed0517abeaf3c7a29611d64546f
I've decided to let the "picking custom fetch headers" feature die with the old IMAP backend after a brief discussion on the mailing list. https://mail.gnome.org/archives/evolution-hackers/2012-December/msg00019.html So 3 down / 1 to go feature-wise + automatic account migration.
Support for server-side "body" search: done. http://git.gnome.org/browse/evolution-data-server/commit/?id=0eb3de7b71e36041a4e208433385d34c37bd7c07 We now have feature parity. Just have to write migration code.
Automatic account migration: http://git.gnome.org/browse/evolution-data-server/commit/?id=cda199f86d740c4db6e9dd532ebfe0da867e8f65 And the coup de grâce: http://git.gnome.org/browse/evolution-data-server/commit/?id=937d6d37240dc81a6cc9d52d6af0521bf462e84c Long overdue, but finally FIXED for Evolution-Data-Server 3.7.4.
Migration seems to not work properly, I see these on console: > (evolution:1402): camel-WARNING **: Could not find a corresponding > CamelIMAPXFolder property for state file tag 0x2500
(In reply to comment #16) > Migration seems to not work properly, I see these on console: > > (evolution:1402): camel-WARNING **: Could not find a corresponding > > CamelIMAPXFolder property for state file tag 0x2500 Fixed in: http://git.gnome.org/browse/evolution-data-server/commit/?id=47825442a2e70e3e4e79414742f8f2194d16d533
The same property ID is used on various objects, thus the change might not be completely right. Maybe the warning itself is useless as such. Another warning, I see this 3 times when I run evolution: > (evolution:24395): camel-WARNING **: Cannot load summary file: Success with the below backtrace:
+ Trace 231358
(In reply to comment #18) > The same property ID is used on various objects, thus the change might not be > completely right. Where? I don't see the 0x2500 property value used anywhere else. IIRC those values had to be unique under the old CamelArg system. > Another warning, I see this 3 times when I run evolution: > > > (evolution:24395): camel-WARNING **: Cannot load summary file: Success That looks to be camel_store_summary_load() mishandling possibly an empty file. The IMAP -> IMAPX migration code moves the account's entire cache directory to trash, which would include ~/.cache/evolution/mail/$UID/.ev-store-summary, so I don't see how this could be a migration issue.
(In reply to comment #19) > Where? I don't see the 0x2500 property value used anywhere else. > IIRC those values had to be unique under the old CamelArg system. My poor memory, I'm sorry. The uniqueness is required for each object, not between objects. The reused value is 0x2400, not the 0x2500. > > > (evolution:24395): camel-WARNING **: Cannot load summary file: Success > > That looks to be camel_store_summary_load() mishandling possibly an empty file. > The IMAP -> IMAPX migration code moves the account's entire cache directory to > trash, which would include ~/.cache/evolution/mail/$UID/.ev-store-summary, so I > don't see how this could be a migration issue. If nothing else then it's new after migration or some recent changes. I do not recall seeing this before the migration, and I had enabled one IMAPx account, thus my first bet leads here.
(In reply to comment #14) > We now have feature parity. Just have to write migration code. Should I reopen this? IMAP folders had a property for automatic update, thus one could set either "update all folders", or pick folders individually for update. I use that, and it was a good feature, used by other people as well (you definitely do not want to update your Archive folder each account refresh, but still want to refresh other that Inbox folders).
(In reply to comment #20) > > > > (evolution:24395): camel-WARNING **: Cannot load summary file: Success > > > > That looks to be camel_store_summary_load() mishandling possibly an empty file. > > The IMAP -> IMAPX migration code moves the account's entire cache directory to > > trash, which would include ~/.cache/evolution/mail/$UID/.ev-store-summary, so I > > don't see how this could be a migration issue. > > If nothing else then it's new after migration or some recent changes. I do not > recall seeing this before the migration, and I had enabled one IMAPx account, > thus my first bet leads here. I think I know what causes this, and the other issue, semi-constant redownload of my IMAP folders (and bet they are large), you move the old cache to trash, but then your cache-reaper will return it back, because the UID didn't change. No prove for it yet, just an idea what can be wrong.
I opened new bug reports and added them to dependencies.