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?
>
> Of the above three mentioned technologies, only Nepomuk is part of
> "semantic desktop".
>
> The other two, while being used by Nepomuk as data sources, have their
> own, orthogonal, use cases.
Yes. You mention strigi's. I'll mention akonadi. Like strigi it has
its use case. In its case it's to unify the backend for the various
kdepim apps, eventually saving time and maintenance effort by replacing
multiple copies of contact information (for example) management code with
a single copy.
While in theory that should eventually be great, it does mean putting all
the kdepim eggs in one (much more complicated) basket, making things much
worse if that basket develops a hole, since now it's the data from all
those apps at risk. Also, there's inevitable growing/change pains, and
getting from here to there isn't an easy process.
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.
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.
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.
And that's what we see, some people choosing to live with the problems,
some people switching to other alternatives, from which many will never
return even after kdepim on akonadi is long since stable.
Was it worth it? The developers obviously thought it was worth the
risk. Users like me are going elsewhere, likely never to return. Others
suffer thru it, and there's always new users after the stabilization.
But the answer those of us forced off have will be very different than
that of the devs, and the new users who didn't have to live thru the
upgrade.
Oh, well... (more below)
> Strigi, or more precisely one of its building blocks ("libstreams"), is
> tasked with providing metadata about files, e.g. artist of a digital
> music file, date/time of capture of a digital photo file, etc.
>
> Such information pieces are nowadays regarded essential by lots of
> users, e.g. expect them to be displayed when hovering over such a file
> or when looking at such a file's properties.
>
> Since the information is also made available to Nepomuk, applications
> can either use the technologies directly (link with libstreams, extract
> metadata when needed) or by quering Nepomuk.
>
> The latter approach obviously requiring Nepomuk to run but on the other
> hand making a bigger set of meta data accessible, e.g. user generated
> meta data such as rating, comments or tags, or application generated
> meta data such as file origin (e.g. the web site is was downloaded
> from).
>
> This type of information is not as expected as the first type, though
> rating is increasingly being used for digital music and comments now are
> often applied to digital photos (description of scenery, people on the
> photo. etc).
>
> It seems the authors of applications dealing with meta data had
> anticipated a faster growth of such needs, thus making the choice of
> augmented data access more desirable.
It's worth noting that with the whole semantic-desktop including the
strigi backends turned off, at build-time where it's possible, there are
some bits of functionality that was in kde3 now missing, because in kde4,
the semantic-desktop services provide that data. Metadata such as jpeg
pixel sizes, comments, etc, is no longer available thru konqueror/
dolphin, etc, because nepomuk and its backends (strigi, tho it's arguably
a "middle end", etc) are now the standard provider of such info in kde,
and I've opted out of them.
But if I need that data, there's other ways to get it, other apps, etc.
And most of the time I can do without.
Choices made, forks in the path chosen. All that semantic desktop stuff
is nice and the devs had their reasons, but I'll live without that
information, or get it from other sources, because the cost in terms of
resources, speed and stability is simply higher than the benefit I get.
One other question is where from here? Luckily for those of us opting
out of semantic-desktop, kde5 aka kde frameworks is supposed to be much
more modular, so hopefully, the interdependencies become less of an issue
not more, and I can continue to opt-out on semantic-desktop, etc, at
build time. Yes, there will be some apps (kmail, etc) that require it to
function, and I don't see that changing, tho there's now an opportunity
for a "lighter" qt/kde mail client, but there's alternatives for those
apps, and a kde desktop should continue to be possible without semantic-
desktop, at least for those willing to build it themselves (as on gentoo
for instance).
I believe and hope, anyway.
Meanwhile, as I've stated before, there's arguably an open niche for a kde
desktop based but "hybrid" binary distro that turns all the semantic-
desktop, akonadi, etc stuff off, using firefox or chromium (because
konqueror isn't a serious alternative any longer) and maybe thunderbird
or claws-mail or evolution, in place of the kde alternatives, It's
doable on gentoo (as is turning it all on), but I don't know of any
binary distro filling that niche, yet, and I believe there's an opening
for one.
--
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.
