Has the KDE Social/Semantic Desktop been worth the hassle to anyone?

[Duncan]

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.