openSUSE KDE Team responds
|
| Author | Content |
|---|---|
| wstephenson Mar 29, 2011 2:23 AM EDT |
Google Alerted me to your post and as I'm directly responsible for providing KMail, please allow me to respond. I hope you won't see this as a high-handed putdown, but as you are in error in several places it would be a disservice to other happy KMail users to let your conclusion, that KMail is unusable, stand. > I am still stuck with 11.2. So when I got a little time on my hands recently I decided to grab me the latest KDE. First a disclaimer: 11.2 is approaching the end of its life (May 12 2011) and while we do provide the latest KDE packages for it (http://download.opensuse.org/repositories/KDE:/Release:/46/o...) we don't test or provide any guarantees that it will work. I recommend using a recent, tested distribution release if your troubleshooting techniques only extend as far as writing angry articles. > To my dismay KMail was complaining about unresolved dependencies! KMail wanted Akonadi (does that sound like anaconda to you?), which in turn required Nepomuk, which wanted MySQL... Darn!!! What method did you use to install KMail? openSUSE Build Service packages? From source? All these dependencies are well known and the standard tools, YaST or zypper on the command line, will install them for you along with KMail. > I was not... and will not.. allow my email to reside in MySQL. This is your first mistaken assumption. Newish versions of KMail and Kontact use Akonadi which in turn use a database as a data *cache*. This is not its permanent store - the data still lives in maildir/vcard/ical folders. This allows KMail itself to be a simpler app and concentrate on the presentation of email. > because I use MySQL (and PostgreSQL if that matters) for so many projects and I often change the Data Directory (datadir directive in /etc/my.cnf) depending on the project I am working on. While I could accommodate a PIM database within a project, I was not sure what would happen when changing from Project A to Project B. You're overthinking this too. The KDE PIM team know that a mail client should work out of the box. If you look in the process list with a running recent KMail you'll see something like this: usr/sbin/mysqld --defaults-file=/home/<USER>/.local/share/akonadi//mysql.conf --datadir=/home/<USER>.local/share/akonadi/db_data/ --socket=/home/<USER>/.local/share/akonadi/socket-emsig/mysql.socket As a heavy MySQL user you'll recognise that the MySQL instance used by Akonadi is started with a custom datadir and config files, and communicating over a dedicated unix socket. It won't ever conflict with your project MySQL instance(s). So in response to your summary: > What were they thinking? To design a common PIM data middleware layer replacing many error-prone per-application caching solutions > Why did they not use SQLite which in my opinion would have been best suited for such a task? An option (used by default on the mobile ports of Kontact) > Why did they not provide an easily configurable mechanism of achieving what was required? As shown above, they did. > Why did they assume that I would have MySQL installed? They don't have to - this is your distribution's responsibility. And our standard tools ensure this. > Why should installation and configuration of an email client be as taxing as if it were an ERP? Why? Why? Why? Most users' experience doesn't match yours, so I guess that a) you were using some non-standard tool to install latest KDE that doesn't handle dependency resolution and b) you then saw "MySQL" and prejudged it based on your own experience of MySQL. |
| macias Mar 29, 2011 2:57 AM EDT |
> Newish versions of KMail and Kontact use Akonadi which in turn use a database [MySQL] as a data *cache*. What will be next? A cluster needed for doing search? I know (as developer) the need for good separation of the programs, but here is example of the overkill. One should keep things as simple as possible, but not simpler. MySQL used for caching (what data, mail?) is not a tool "as simple as possible". No wonder, with all fast computers we are not more productive because of all hevy-weight processes running in the background and slowing down overall performance. Not mentioning bizarre UI approach (in general; here I have just a few complains for KMail). You can of course reason why this or that decision was made, but I see the outcome and it is no-go for me. Maybe at some point new KMail will be as good as its KDE3 version, maybe not -- it is not up to me, but it is up to me to choose the best one. For now it is KMail/KDE3. |
| hkwint Mar 29, 2011 3:09 AM EDT |
Hi Mr. Stephenson, Many thanks for replying. I think many users have questions about MySQL / KMail (and hence why it's in the FAQ). On behalf of the LXer editor-team I'll put a line at the end of the story linking to your answer above. On a personal side note, is it correct newer versions of KMail default to SQLite? During update to kde-base/kde-pim-meta-4.4.10 on Gentoo (using standard portage / ~x86), in one of the configuration files in /etc/ I noted MySQL was replaced by SQLite, does that it's using SQLite now? |
| hkwint Mar 29, 2011 3:38 AM EDT |
macias: The developers tried answering those questions in the FAQ; here |
| wstephenson Mar 29, 2011 3:48 AM EDT |
> On a personal side note, is it correct newer versions of KMail default to SQLite? During update to kde-base/kde-pim-meta-4.4.10 on Gentoo (using standard portage / ~x86), in one of the configuration files in /etc/ I noted MySQL was replaced by SQLite, does that it's using SQLite now? That's not correct. The upstream default for Akonadi for desktop KMail/Kontact is MySQL. For mobile Kontact it's sqlite. I assume Gentoo has changed that setting. The background story is that when Akonadi started there were severe performance problems with multi-threaded sqlite; however there was no way, even with the aggressive slimming down used in the desktop configuration, to make MySQL fit onto WinCE 6, so the team fixed some sqlite problems and found workarounds for others. This makes sqlite a viable option on the desktop too, although MySQL or PostgreSQL perform better. |
| tuxchick Mar 29, 2011 9:06 PM EDT |
I'm sorry but this sounds very over-complicated. Why use a database cache at all? tmp files work fine for other mail clients. All of these obese dependencies may make sense inside KDE, though I question that too, but they're a heck of a lot of baggage for running Kmail standalone or in a different desktop environment. What about users who don't want a great giant do-everything PIM environment, but just a nice POP/IMAP client? With a nice simple plain-text addressbook, which is easily recoverable and portable. What is the advantage to the end user of breaking Kmail into chunks and spreading it over all these weird subsystems? All I see is more drain on system resources, more complexity, more things to break, and more difficulty for users to ever understand, debug and correct their own systems. Certain tasks need to be done whether they're included in Kmail or shifted to something else; there is no free lunch. Since binary indexes are a problem, and that seems a weird design decision in the first place, XML files like other mail clients use seem like a perfectly serviceable solution. I don't think it's users like macia who are overthinking. |
| hkwint Mar 30, 2011 4:39 AM EDT |
TC: Obviously, "one size fits all" doesn't fit all users! Given I'm on a source based distro, I agree; you don't want to know how long it takes compiling KDE-PIM + dependencies. Have been using KDE-PIM since 4.2, and even while I'm now at 4.4.10, NEPOMUK still gives errors - like "not registering at dbus" and such. One gets used to it. Starting Koncact, clicking "ok" in the "error-list", downloading my mail and scanning it - using SpamAssasin's daemon spamd - usually takes multiple minutes. While scanning, Kontact is unresponsive. Maybe a bad SA configuration, I can't tell. Of course, 4.6-beta (or something like beta) is available now, but I don't trust beta software with my e-mail. I was looking for an alternative as well, I liked your Balsa-recommendation (IIRC it was you who advised it). But I was not sure how to export my current mails to Balsa, and since those mails are crucial to me, I'm still stuck on KMail. The question as to 'why' has been answered before I think: Currently it was pretty impossible for "PIM-like" programs to communicate between each other, so many ad-hoc dirty hacks were employed. I think the common middleware-libraries are aimed to solve this. Result is, the end-desktop user is left with software for which it's a requirement also to be able to run large groupware servers. |
| tuxchick Mar 30, 2011 10:43 AM EDT |
Hans, you should be able to open your Kmail stores directly in Balsa, without needing an import tool. I think you just copy them to the Balsa directory in your homedir; I'll check later when I'm on a different computer. I understand the bit about needing a good PIM framework. I don't understand goofy stuff like Kmail cannot function as a standalone mail client without dragging in the entire akonadi/nepomuk/mysql framework, because Kmail is now only for "presentation of email", which seems to mean that functionality that used to be in kmail is now somewhere else, and Kmail is no longer portable outside of KDE4. Not without dragging in all this framework stuff that lives only in KDE, so now we're in the fun situation of both Gnome and KDE4 having redundant complex frameworks of all kinds, so they're farther apart than ever. And that running mixed systems means installing vast quantities of extra baggage, and maintainers of other graphical environments have to work harder than ever for what should be standard, boilerplate integration such as system menus and appearance. It's like going to a restaurant for a hamburger and you get served a giant pot of beef stew. Where's my hamburger? It's in there, inside its cool new framework. Eh, I suppose someday it will all get sorted out. The price of continual improvement, I suppose. |
| hkwint Mar 30, 2011 7:14 PM EDT |
TC: I think that's a very nice summary of the situation! Running KDE-PIM for several months even messes up your mind. Like thinking:Quoting:you should be able to open your Kmail stores directly in Balsa "No, life can't be that simple. It's impossible. It's morally wrong. It's not the way it was designed. It's not the way the world ought to work. It simply won't compile that way. It will give me a selftest-dialog-box with 3 errors and 23 warnings with 12 clues of how to fix my my.cnf, configure the InnoDB storage log level and configure things through the systemsettings command, which of course I have to emerge first. There should at least be some added generic multiple framework specially crafted middleware incompatability layer to prevent said wanted behaviour, right?" Thanks for helping me out! Other than that, I owe many thanks to the KDE-PIM team, but I think the "one size fits all" doesn't fit me anymore. It was great while it was a fast way to check / read my mail and didn't bother me with error listings, but after two and half year (wow, have I been on KDE4 that long already?) of keeping up with it I'm afraid I'm moving on. And maybe come back when KDE-PIM 4.6 is stable. In the mean time, I might try to compile the 4.6 version just to test it and maybe help with error reports, but I'll keep it separated from my valuable mail. |
| tuxchick Mar 30, 2011 7:56 PM EDT |
LOL Hans! Well OK then I'm going to continue being immoral :D In Balsa you can open any MH, mbox, or maildir by right-clicking in the folder view and then click on New, which opens a filepicker. ./balsa/config is simple and understandable just like config files are supposed to be. |
Posting in this forum is limited to members of the group: [ForumMods, SITEADMINS, MEMBERS.]
Becoming a member of LXer is easy and free. Join Us!