Martin Bednar posted on Sat, 17 Nov 2012 18:13:58 +0100 as excerpted:
> Le samedi 17 novembre 2012 16:30:05 Duncan a écrit :
>> Kevin Krammer posted on Sat, 17 Nov 2012 14:29:22 +0100 as excerpted:
>> > On Saturday, 2012-11-17, Jerome Yuzyk wrote:
>> >> With all the hassles added by Akonadi and Nepomuk and Strigi for
>> >> some higher "social/semantic desktop" purpose, does anyone actually
>> >> _use_ the stuff?
>
>> The database backend is both the trouble and savior in many ways, as
>> databases are notorious for causing "ordinary users" (and not so
>> ordinary ones as well) quite the headaches, not always being perfectly
>> reliable without "professional" management, etc. Sure, high-volume
>> commercial stuff couldn't do without databases, but just to take mysql
>> as an example since that was the first and probably most common akonadi
>> backend, it's known for database version upgrades that need extra steps
>> taken to manage the data format upgrades, and for such details as time
>> and character- encoding (unicode/etc) format issues that database pros
>> deal with and configure as a matter of course, but that simply aren't
>> appropriate for end users to be dealing with. Yet that's now what end
>> users will HAVE to deal with, as kde and mysql upgrade with their
>> distro version, and they find their old contact information not making
>> the upgrade in one piece with them.
>
> IMO that is a distro QA problem. Being a Gentoo user too, reading news
> is all I ever needed to do to keep my system clicking.
It ends up being a distro QA issue, but really, the problem is above the
distro. I've seen at least one kde dev mention that had they known about
mysql when they chose it as the first "stable" backend, what they know
about it now, the choice may well have been different, even tho the
reason mysql was first was because it was more ready than the others
(sqlite, the newer default, wasn't properly thread-safe at the time, work
had to be done to make it so, postgresql has AFAIK remained
"experimental" the whole time, I'm not sure why, but it apparently has
issues that aren't easy to fix, virtuoso was AFAIK very new and kde was
the first big project to use it like that...).
The primary reason (I believe) is because mysql doesn't guarantee
database compatibility between versions (they have seperate maintenance
release series that remain compatible within the series, but consider
people like me that were using pre-akonadi kmail for nearing a decade,
across multiple distros and of course many upgrades, such series
eventually simply fall so far behind current that it's impractical for a
distro to continue shipping them). There's generally a conversion
process available, and the big database sites do it first with a test
installation, then setup a new system with it and test it, then migrate
production to the new/tested setup, but that's not the type of thing joe
blow end user can be expected to do, across tens of thousands of joe blow
end users.
So at some point when whatever mysql series people started with is
upgraded, all those people still on mysql as their akonadi backend are
going to have a problem.
In addition to that, there's at least two separate issues (as I
mentioned) related to mysql internal string formating, (1) UTF-8 or
whatever, and (2) timekeeping (timezone and/or region for holidays, etc,
IDR the details). These are now documented in the kde techbase akonadi
article, because a lot of folks had problems with them. Again, the root
issue is that mysql is targeted at professionals, people who run
databases for a living, with X-thousand transactions a second or at least
in a day. These sorts of folks will EXPECT to be setting this sort of
database operating parameter, and these two will likely be just two out
of dozens of tweaks that they do to setup and tune their database for
good performance in their specific situation.
But this is exactly the type of thing you do NOT expect of an end-user.
Yet, that's what they're left to do when mysql is used as the backend,
and they start having problems because these settings were NOT setup
correctly.
For this and other similar reasons, had they the chance to do it over
again, had they known about all these mysql complications, they'd have
likely waited until sqlite got its thread-safe updates that have allowed
it to be the new default. It's not as powerful as mysql and isn't really
designed for thousands of transactions per second, but it shouldn't have
a problem with the few dozens of transactions per day, maybe a few
hundred for more active users, that the typical kmail/akonadi user is
likely to have. The format it's using is apparently stable, so there's
unlikely to be the upgrade issues, and it's not as fancy, so "just works"
without setting the variables that mysql needs set to work without
potential issues.
But, there's another wrench thrown into the works for akonadi and mysql
as well. Unlike most of the rest of kde, where system defaults don't
normally get written to the user config, only changes FROM the system
defaults, in the akonadi case, it writes the backend used into the user
configuration as well.
Which creates a problem, because normally, system upgrades don't touch
the user's home dir or the user configuration details stored therein. So
guess what. When the upstream and most distros default switched to the
now ready sqlite backend, many users continued using the old mysql
backend, along with its more complicated issues, because the backend
choice is written into the user's own configuration, even if they never
changed it from the system default. So the system default changes, but
the user specified configuration doesn't change with it. Normally that's
a good thing, because the user specified configuration was a change FROM
the default, thus something the user did deliberately. Unfortunately in
this case...
So a lot of the early kde4 users are still using the akonadi mysql
backend, even tho the sqlite backend is more appropriate and is now the
default. And it's a bit of a time bomb, because at some point the system
mysql version's going to change series, and their old database will break
against the new mysql. But by the time it does so, the sqlite backend
will likely have been the default for several years, and few distro kde
folks are likely to remember that mysql was the default way back in early
kde4, so they'll likely be expecting the sqlite backend default and will
be looking for the problem in the wrong place when it finally triggers.
It really is more of a mess than I think many, certainly many users,
realize.
>
>> Plus, if there's a bug, binary formats are notoriously difficult to
>> repair and are arguably less robust, compared to "plain text" and
>> perhaps XML for contact info, etc.
>
> You should never have to worry about the akonadi database : it's only a
> cache.
> This means that all the data is stored somewhere else (whether it be
> IMAP, POP, maildir, carddir), and that data is plaintext (or whatever).
> Akonadi resources only unify data sources.
You're right... in theory. But in theory, theory and practice are the
same. In practice... not so much.
>From the user perspective, one or several messages, contacts, whatever,
simply disappear. Yes, if they hold their ear just right while hopping
on one foot and yodeling some obscure tune from 14th century China, and
if they remember to do that BEFORE doing anything else that might delete
the backup version permanently, with luck, they can get the message back.
Actually, I know from experience it feels pretty close to that,
especially about the third or forth time in a week you end up deleting
the cached info to let it rebuild, because yet again it lost something,
because that's precisely the spot I found myself in, when the question
suddenly occurred to me, Why am I putting up with this, in my mail client
of all things, which SHOULD "just work". After all, kmail "just worked"
for nearly a decade for me... until they started trying to fix what
wasn't broken! It was at that point that I realized kmail was no longer
the right mail client for me. I wanted a mail client that "just worked",
like kmail had "just worked" for me for years, not something I had to
hold my ear just right every time I checked mail, lest something
disappear and have me (feeling like I'm having to be) yodeling 14th
century Chinese tunes to bring back, what SHOULD have been ABSOLUTELY
STABLE, no loss of data in the first place!
And at least for me, claws-mail is if anything, an even better match for
me than kmail was, for all those years. =:^) I really enjoy the
scriptable extensibility and have actually created one script already,
taking advantage of that. Of course it's exactly the same thing that
makes gentoo the perfect distro match for me, I LIKE being able to
control it at exactly the level I want, overriding any defaults I don't
like, changing functionality if necessary, etc. =:^)
Anyway, again, that's not the sort of thing an end user should be having
to worry about. Mail should "just work". And for me, just as with old
kmail, but unlike the new akonadified kmail, claws-mail does just that,
actually works, dependably, every time. No missing mails. No jumping
thru hoops or yodeling obscure 14th century Chinese tunes while hopping
on one foot and holding my ear just so, to try to get them back.
>> Five years down the line, it might be stable. Thunderbird and
>> evolution both depend on database backends (sqlite I believe, now a
>> choice for akonadi as well, tho it wasn't originally, and a lot of
>> folks are still using the mysql backend) and they aren't considered
>> /terribly/ unstable. But they've had years... the better part of a
>> decade I guess... to mature. What are long-time kmail/kdepim users
>> supposed to do while it's stabilizing? Basically, they're left either
>> dealing with the problem as kdepim slowly stabilizes on akonadi, or
>> switching to something more reliable in the mean time, from which many
>> will never switch back.
>>
>>
> just my $0.02 : akonadi/SQlite user here, works like a charm. (maybe
> slower than with mysql, never benchmarked, also my email collection is
> "small" compared to what I've heard from other people)
Yeah, the sqlite backend is better, as explained above. But at least
with the kdepim I left it with, it wasn't /reliably/ stable. I actually
think it's reasonably stable now (definitely more so than when I left,
from what I read, tho I know some still reporting problems), but now is
too late, for me. They tried to fix what wasn't broken, breaking it in
the process, and regardless of whether it's fixed now or not, I moved on,
to a solution that continues to "just work", and that's extremely
unlikely to ever have this sort of change occur, because of all the user
scripts it would break, the ability to have those scripts being a major
feature of that program. =:^)
> IMO the akonadi change was worth it, I see possibilities everywhere with
> this framework.
Like I said, I know why they did it. And I can't entirely disagree. But
I don't like /how/ they did it. And meanwhile, while I don't disagree
that it does open the way to a lot of new features and flexibility, the
direction they're going really isn't one I'm interested in following them
on. So I just go my way and they go theirs.
Which is more or less what I said about the whole semantic-desktop thing
in general, too. There's reasons for it, and people for whom it's a big
improvement. But that way is simply not my way. Luckily, with the
semantic-desktop in general, kde made it an option. And maybe eventually
there will end up being kde options to where kdepim is going too. They
just aren't there yet.
> I see you mentioned "lightweight mail client"; did you
> hear about Trojita (IMAP only)?
Yes. Actually, I've been following it reasonably closely, altho all my
mail providers are POP3 not IMAP so it's not something I can easily use
personally ATM. But I've already recommended (with the caveat that it's
still rather new and not yet fully mature, they should consider it the
still under development app it is) that people put it on their "checkout"
list a number of times, when people posted questions asking about kmail/
akonadi alternatives.
Furthermore, as the trojita primary dev is a gentooer too, actually a
gentoo dev, his blog is on gentoo-planet, which I subscribe to the feed
from. And a few days ago he blogged about it, saying it was in general
fully functional now altho still a bit rough in spots, and inviting
people to mail him with questions, etc. I took him up on the offer,
mentioning my activity here and the fact that I've recommended that
people with IMAP providers check it out, with the caveat that it's still
under development, etc, and asking a few questions in that regard, plus
about where he thought qt5 was headed, etc (he was blogging from a qt
developer conference).
I did mention that with permission I might end up posting bits of his
reply where it made sense to do so, and he said that was fine. So if
you're interested, I can do so here/now (tho I'd probably start a new
thread with it).
Trojita really is the sort of thing that makes me wish I had IMAP, as it
really looks quite interesting. I even thought of setting up my own IMAP
server and using fetchmail or whatever to grab from my providers, just to
give me both a chance to learn about IMAP and a chance to try trojita,
but I haven't yet and in practice, probably won't. But if I end up on a
provider that has IMAP, you can bet trojita's on my list of things I'll
try on it. =:^)
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
___________________________________________________
This message is from the kde mailing list.
Account management: https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.
