On Tuesday 22 Nov 2011 08:17:52 Linda Walsh wrote:
Herbert Graeber wrote:
Automatic
migration is the culprit here. Dropping it and let the user do the migration himself (like he needs to do for migration to other email client as well), would save much time an pain.
------------- Maybe it is too radical for most people, but I've been running imap since the mid-late 90's. I did so for exactly the reason you have above -- having to deal ( or sometimes wanting to try) multiple email clients. Any email client that tries to store stuff in a private store.
Evil.
I ran it on the same machine I ran the email clients -- just to separate the mail storage from the email clients and allow all of them to play together. Since then IMAP has only been improved with indexing and search support.
Maybe the default on suse should be to install an imap server (partial to dovecot here at this time...was on UW-IMAP in past)... and have clients use that locally via loopback. That way -- no need to migrate mail...
If you were to connect to Akonadi's local socket (as you can do with akonadiconsole->Raw Socket) you would currently see * OK Akonadi Almost IMAP Server [PROTOCOL 28] Guess what, we did put an imap server with a relatively dumb email client on the desktop. [ Internet ][ Local system ] ( IMAP server) <IMAP> (IMAP resource) <IMAP> (akonadi server) <IMAP> (KMail2) ( POP server) <POP> (POP resource) <IMAP.... .... Local, temporary changes to IMAP mail and the offline cache are stored in the 'evil' private SQL database, but POP mail and other local data are stored in standard format files on disk. We used IMAP for message/item transfer instead of DBUS because IMAP is lightweight and suited to large transfers, and won't load the session DBUS. (DBUS is used as a side channel for resource control). The reason the protocol is called 'Almost IMAP' is because it doesn't need to provide a complete IMAP implementation, and some extensions were added to allow conflict resolution and other Akonadi specific things that I don't remember. We considered dovecot and cyrus before implementing our own stuff, which I also forget the details of, I'll ask upstream. There's nothing KDE specific to Akonadi, and the implementation is pure Qt, so there is no political hindrance to other clients supporting it. Oh, and making KMail a frontend to evolution-data-server was considered in detail, but e-d-s only supports contacts and calendar data - email is all in Evolution. AFAIK e-d-s as desktop email middleware is still being worked on. Will -- Will Stephenson, openSUSE Team SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org