No risk no fun ! Dachte ich und habe mir mal KDE 4.6 Beta auf einem meiner Opensuse 11.3 Systeme installiert. Aus drei Gründen war das für mich ein interessantes Experiment :

1. Weil unter KDE 4.5.2, KDE 4.5.3 K3b nicht mehr funktionierte und ich gemäß der Einträge bei den entsprechenden KDE-Bugs aber die Hoffnung bekam, es könne nun wieder laufen.
2. Weil unter KDE 4.6 das Akonadi-Subsystem nicht mehr nur für das Adressbuch sondern auch für die Verwaltung der Mailordner zuständig wird. Hier ist das Wechselspiel mit IMAP-Systemen interessant.
3. Weil Akonadi auch mit den Kalender-Ressourcen eines Open-Xchange 5 Servers zusammenarbeiten sollte.

Um es vorweg deutlich zu sagen: Solche Experimente mit Beta-Systemen wie zu Punkt 2 sollten keine produktiven IMAP- oder OX-Server einbeziehen, sondern nur Server, die Kopien der eigentlichen IMAP-Mail-Ordner und Kalenderdaten beinhalten! Zur Not richtet man sich einen IMAP-Testserver halt auf einem Laptop oder einem virtuellen System ein. Bei OX5 oder OX6 ist das zugegebenermaßen schon schwieriger.

Zu Punkt 1 – K3b:

K3b läuft unter Opensuse 11.3 und KDE 4.6 wieder – allerdings nur mit den letzten K3b RPM-Paketen 2.0.1-44.1 im Opensuse Factory Repository. Eine CD habe ich mal testweise gebrannt – das lief ohne Probleme. Genauer getestet habe ich das Brennen von unterschiedlichen Medien (DVD+-R, DVD+RW, etc. aber noch nicht. Das Rippen von CDs läuft mit der aktuellen Version aber wie gewohnt. Anzumerken bleibt: Die aktuellen RPMs von Packman 2.0.1.pm.2.26 laufen nicht. (Vermutlich wegen der erfolgten Änderungen im HAL-Bereich)

Zu Punkt 2 – Kmail, Akonadi, IMAP – und die problematische Wirkung von Filtern :

Die Verwaltung von Mailordnern durch Akonadi stelle ich mir persönlich als eine komplexe Angelegenheit vor. Im Besonderen dann, wenn die Mailordner auf einem IMAP-Server liegen und die Filterung von Mails (Spam und andere Filter) aber lokal unter KDE’s Kmail erfolgt. Ich habe auf meinem Desktop-System eine ganze Reihe von Filtern eingestellt. Nicht nur zum zusätzlichen Filtern von Spam, der auf dem Server nicht erkannt oder zu vorsichtig behandelt wurde, sondern auch themen- und kundenbezogene Filter.

Für mich als Anwender stellt sich doch die Frage, wie der mindestens zweistufige Weg der Filterung von Kmail über die Akonadi-Maschinerie hin zum IMAP-Server abläuft. Kmail als Frontend zu Akonadi initiiert die Filterung und als Reaktion werden dann ggf. Verschiebungen von Mails aus dem Posteingangsordner hin zu anderen Ordnern durchgeführt. Das Ergebnis muss sich zunächst auf dem lokalen Akonadi-System und dessen Abbildung der Mailordner niederschlagen. Die vorgenommenen Ergebnisse der Filteraktionen wie Löschungen im Ursprungsordner und entsprechende Neuzugang in definierten Zielordnern müssen ja aber auch periodisch zwischen Akonadi und dem IMAP-Server abgeglichen werden. In einer solchen Verarbeitungskette – MUA-Client <> Akonadi (als zwischengeschobenes zentraler Puffer) <> IMAP-Server – eröffnen sich zahlreiche Möglichkeiten für Fehler.

Meine Erfahrungen waren entsprechend :
Die Migration der vorhandenen Mail-Ordner aus dem alten Kmail hin zu Akonadi ging grundsätzlich ohne Probleme vonstatten. Es dauerte allerdings etliche Minuten, da unsere Mailordner mehrere Gigabyte umfassen. Die Zeitdauer für die Migration war aus meiner Sicht absolut OK. Probleme verursachten dann aber die bereits konfigurierten Mail-Filter aus meiner KDE 4.5.3-Kmail-Version. Diese fingen nämlich beim Füllen meiner doch zahlreichen Mailordner an zu wirken – und zwar nicht in der gewohnten Weise. Es wurde in andere lokale Ordner verschoben, die begonnen Filtervorgänge schluckten
enorm viel CPU-Zeit, die Kmail-Oberfläche kam letztlich zum Stillstand und war nicht mehr bedienbar …. Ursache war hier vermutlich, dass viele Mailordner im Zuge der Migration gleichzeitig neu befüllt wurden.

Kurzum:
Die Filter verursachten zeitversetzt und im Nachgang zum eigentlichen Migrationslauf zunächst ein ziemliches Chaos und ungewohnte Verschiebungen in lokale (!) Spam- und Trash-Ordner. Offenabr war ein teil der alten Konfiguration – nämlich die Festlegung der Zielordner – verloren gegangen. Nun ließen sich die laufenden Filterprozesse wegen des Stillstands der Kmail-Oberfläche leider auf konventionellem Wege auch nicht mehr aufhalten. Ein Killen der entsprechenden Prozesse, ein Löschen der Konfigurationsdatei kmail2rc und ein Neustart verhalfen mir schließlich zu der Möglichkeit, meine Filter zu entfernen und komplett neu anzulegen. Danach verhielt sich Kmail ruhiger und ließ sich fast (s.u.) normal bedienen. Die fälschlich verschobenen Mails habe ich dann wieder in ihre Ursprungsordner einstellen können.

Ich kann daher jedem, der größere Mailordner sein eigen nennt, nur raten, vor einem Umstieg auf das neue KDE und sein Kmail alle eingerichteten Filter zunächst mindestens zu deaktivieren, wenn nicht gar zu löschen – und sie erst im Nachheinein neu einzurichten.

Aber auch dann bereiten die lokalen Filter in Kmail noch weitere Probleme:

Im Gegensatz zu früheren Kmail-Varianten werden nämlich alle auf dem IMAP-Server für das Löschen markierte – aber im IMAP-System aus den Ursprungsordnern physikalisch noch nicht gelöschte Mails – erneut in den Mail-Ordnern von Kmail angezeigt (in grauer Schriftfarbe). Regeln zur Kompaktifizierung der IMAP-Ordner – sprich zu einem sofortigen Löschen von Mails in den IMAP-Ordnern auf dem Server – sind bei mir deaktiviert. Mails werden daher auf dem IMAP-Server bei Lösch- oder Verschiebe-Vorgängen in ihrem Ursprungsordner nur zum Löschen markiert. Die eigentlichen Löschungen laufen dann am IMAP-Server zwar periodisch, aber mit deutlichem zeitlichem Abstand. Das ist eine reine Vorsichtsmaßnahme, von der die User an ihren Clients (wie dem alten Kmail) normalerweise gar nichts mitbekommen.

Aus der Anzeige der zum Löschen markierten Mails in Kmail lässt sich schließen, dass Akonadi beim Filtern und Verschieben der Mails in neue Ordner also mitbekommt, dass die verschobenen Mails auf dem IMAP-Server noch im Ursprungsordner vorhanden sind – wenn auch mit geändertem Status. Nun wirkt sich das leider negativ auf die Filter in Kmail aus. Die Filter bewerten die markierten Mails offenbar als neu eingegangene (möglicherweise wegen der Statusänderung) und filtern sie deshalb auch erneut. Obwohl sie ja schon früher behandelt und in andere Ordner verschoben wurden. Und das setzt sich dann so fort ….

Ergebnis:
Nach einigen periodischen Abgleichen zwischen Akonadi und dem Imap-Server wächst der Inhalt in Trash oder Spam-Ordnern linear an. Mit immer den gleichen Dateien. Das ist im Produktivbetrieb ein Desaster. Als Anwender kann man hier das Gesamtsystem nur so einstellen, dass bei der Löschung/Verschiebung einer Mail aus einem Ordner durch eine Kmail-Aktion auch eine sofortige Löschung der Mail in ihrem Ursprungsordner auf dem IMAP-Server vorgenommen wird. Das ist zumindest riskant. Oder man muss die Filter um sehr spezielle Einstellungen und Kriterien erweitern – was man vom normalen User nicht verlangen kann.

Die Lösung aus meiner Sicht wäre eine andere Behandlung von Mails, die auf dem IMAP-Server zum Löschen markiert sind, in Akonadi wie in der Anzeige und den Filter-Routinen von Kmail.

In der jetzigen Form ist das Kmail/Akonadi-Verhalten im Zusammenspiel mit IMAP-Servern zwar schon erstaunlich stabil und auch die Migration der Mailordner zu Akonadi-Ressourcen funktioniert im Kern schon richtig. Aber die Behandlung von Mails, die aufgrund von Client-Aktionen auf den IMAP-Servern zum Löschen vormarkiert werden, muss für den produktiven Einsatz geändert werden.

Hinzu
kommt ein weiteres Problem, dessen Ende ich auf meinem Versuchssystem noch nicht absehen kann. Mindestens am ersten Tag der Umstellung fraß der “virtuoso-d”-Prozess mit führendem Abstand die allermeiste CPU-Zeit auf meinem System (in Form von nice-Last). Ursache ist die Indizierung von Mails durch Nepomuk mit Virtuoso als Backend (virtuoso-t ist wohl ein zugehöriger Datenbank-Prozess).

Dabei war die Konkurrenz um die Prozessorzeit keineswegs gering – auf zwei von 4 CPU-Cores habe ich andauernd unter VMware auf einem virtuellen Windows-System gearbeitet. Normalerweise würde VMware die meiste CPU-Zeit beanspruchen. Bei KDE 4.6 Beta war es bislang aber der Prozess “virtuoso-d”. Er verbrauchte doppelt soviel CPU-Zeit wie VMware – und zwar im bereich mehrerer Stunden. Das ist wirklich viel!

Ob das daran liegt, dass ich Gigabytes an Mails habe, vermag ich im Moment nicht zu sagen. Ich hoffe jedenfalls noch, dass “virtuoso-t” nach vielleicht weiteren 12 Stunden endlich Ruhe gibt. Im Moment ist er immer noch fleißig am Werkeln. Fairerweise muss ich sagen, dass vituoso-t sich auf einen Prozessor-Core beschränkt und nach ersten Eindrücken auch nur dann so richtig aktiv wird, wenn tatsächlich noch CPU-Zeit verfügbar ist. Na ja, wir werden sehen, ob die Nepomuk- Indizierung auch mal zu einem Ende kommt. Insgesamt ist das Ganze aber in Indiz dafür, dass man Virtuoso oder aber das Zusammenspiel von Akonadi und Virtuoso ggf. noch effizienter machen muss.

Im Moment würde ich wegen der geschilderten Erfahrungen noch niemanden raten, auf produktiven Systemen auf das neue Kmail umzusteigen.

Zu Punkt 3 – Korganizer, Kadressbuch, OX5:

Das funktioniert im Moment schlicht und einfach nicht. Die Einrichtung von Kalendern als Teil einer OX5-Verbindung zu Kontakt scheitert. Einen entsprechenden Bug habe ich eingestellt. Das ist für mich im Moment übrigens der Hauptgrund, bei KDE 4.5.3 zu bleiben.

Auf einige Ungereimtheiten beim Umgang mit dem OX5-Adressbuch mag ich hier nicht mehr eingehen. Das läuft zwar als Relikt aus 4.5.3 zwar irgendwie, aber dennoch habe ich den Eindruck, dass die zugehörige Akonadi-Ressource nicht wirklich migriert wurde. Denn wenn ich auf die Eigenschaften der entsprechenden Akonadi-Resource zum OX5-Adressbuch gehe, öffnet sich ein Dialog zur Migration – in dem leider Open-Xchange gar nicht als Alternative erscheint. Womöglich arbeitet das “übernommene” Adressbuch also auf einer alten, nicht upgedateten Akonadi-Resource, die keine Verbindung zum OX-Server mehr aufweist. Bin im Moment aber zu faul, mir das genauer anzusehen.

Fazit:

Interessant war es schon, Akonadi nun mal im breiten Einsatz für Gigabytes an Mail zu sehen und nicht nur als Quelle für simple und in der Anzahl überschaubare Adressbuch-Daten. Im Kern funktioniert das schon. Bis auf “Kleinigkeiten” wie die Anzeige von zum Löschen markierten Mails des IMAP-Server und die Behandlung von Filteraktionen für solche Mails.

Ich bin daher sehr gespannt, wie sich KDE 4.6.Beta 2 bzw. der Release-Kandidat präsentieren werden. Im Moment ist Kontact KDE 4.6 in unserem Arbeits-Umfeld jedenfalls noch nicht reif für den produktiven Einsatz. Was ich bei einer ersten Beta-Version auch keinesfalls überbewerten will, sondern als normal ansehe.

Nachtrag: Problem mit der FROM-Adresse

Gerade macht mich meine Frau darauf aufmerksam, dass Mails, die ich von meiner Testinstallation verschicke, eine leere FROM-Envelope-Adresse aufweisen. Dies geschieht seit der Installation der letzten Kmail-RPM-Variante 4.5.80-261.2 vom Opensuse Factory-Repository unter KDE 4.6 Beta. Obwohl alle notwendigen Daten in der Kmail-“Identität” gepflegt sind. Na ja, Beta halt ……