Will Stephenson <wstephenson@suse.de> writes:
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]
So does that mean I could connect with a different IMAP client (Emacs Gnus?) and expect it to work?
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.
Where's a documentation of this? Please, no blog postings or some offshoot remark in a bug database... Now, back to the start of this thread and the question was if KMail2 should be shipped to _users_ (not developers). KMail2 itself might actually work OK and things might go swimmingly if I had started with a fresh setup. However my KMail setup goes back to SuSE6.2 and the migration process clearly hasn't been tested on "grown" setups like mine and the diagnostics are lacking any form of useful feedback of what exactly makes it choke. Indeed it cheerfully told me after a few edits in my kmailrc and cleaning out unused folder from my mail directory that "Migration completed successfully.", even though I did not have access to any of my old mails. The same lack of useful diagnostics is apparent in all of the backend infrastructure. Yes there's akonadiconsole, but nothing like that for Nepomuk or Soprano. So, I have to attach myself to DBus to maybe see what is going on and I still haven't found a way to ask if a particular entry has been indexed or not. I'd really want to see this directly in KMail, just like you can see if the mail has been read or not. I'd even want to tell it which mails to index and more importantly when. I didn't think migration would be that bad, but it's been a full week now that I'm trying to get my mail back. Not only does the "automatic" migration not work, manual migration has also proven impossible in my case. I've had to re-create my setup almost from scratch and even then backtrack a lot, often losing a day worth of work already done. The akonadi_mixedmaildir_resource (the one that supposedly reads the old KMail folder structure with mbox and maildir mix) only finds the folder structure, but never actually shows any mail (reported as bug #732883).
From akonadiconsole I can see that the first folder it tries it's hand on it will get stuck and then it just stops responding. Additionally I get a "Local Folder" since the migrator doesn't deal gracefully with the default structure that a fresh akonadi start creates.
When or rather if it finishes indexing my mail this time I'm almost done (there are two folders that I missed to import). The crucial step was to completely remove _all_ pre-existing databases and migration resources: rm -fr ~/.local/share/{{,.}local-mail{,.directory},akonadi} ~/.config/akonadi/ ~/.kde4/share/{config/{k{res,mail}{2rc,-migratorrc},akonadi*,specialcollectionsrc},apps{kmail2,nepomuk/repository/main/data/virtuosobackend} Even then, I've had to edit and kill/re-start processes a lot. It is almost impossible to find out what exactly goes on within Soprano and Nepomuk even when you snoop the D-Bus and there seems to be no tool to diagnose/control them (which is a bad thing in itself). I've had to stop Nepomuk and remove all feeder agents before importing the old mails and copy all entries in akonadiconsole. Doing it through KMail2 would crash the machine after a while and not all mails were copied and indexing the mail during a move or copy seems to produce a lot of errors that may have contributed to later crashes and mails missing in the index. As to the copy problem in KMail, I believe if you do a "select all" on grouped mails and then either a copy or a drag-and-drop, only the visible first mail in each group is actually copied. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Waldorf MIDI Implementation & additional documentation: http://Synth.Stromeko.net/Downloads.html#WaldorfDocs -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org