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

Kevin Krammer krammer at kde.org
Sat Nov 17 17:21:34 GMT 2012


On Saturday, 2012-11-17, Duncan wrote:

> Yes.  You mention strigi's.  I'll mention akonadi.

The previous mail would have been too long if I had gone into that area as 
well. I should probably write another reply to that mail that dicusses the 
second topic.

> 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.

Yes, more or less.

> 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.

Well, this has been the case before and is also the case for any alternative 
solution. E.g. if one is using Thunderbird with its Lightning extension for 
calendaring and there is a problem with the program, one loses access to 
mails, calendar and contact as well.

Ultimately there is almost always a single point of failure unless we are 
talking about a high-availability setup.

> 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.

Absolutely, hence the usage of standard text based formats for storage of data 
in KDE applications. Since you list contact info as an example, the preferred 
storage format for it is vcard 3.0 formatted files [1] .

> 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.

Or using the pre-Akonadi versions of the programs in question, e.g. KMail 1.13 
(that's what I do)

> 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.

As I explained in the previous mail, using strigi or rather its meta data 
extraction library libstreams directly was and still is an option application 
authors can use.
As also mentioned before, certain usage pattern indicated a growing need for 
extended meta data, thus leading lots of application authors to chose an 
approach capable of delivering on that front. That need might not have 
materialized (yet?), but at the time of choosing it looked like it would.

Add to that the fact that most KDE developers are Linux based and favor the 
traditional Unix approach of sharing data and functionality through services.

Cheers,
Kevin

[1] Just as a reference: Mozilla Thunderbird currently uses a Mozilla internal 
format called Mork to store addressbooks, with the goal to switch to contacts 
stored in an SQLite database: 
https://bugzilla.mozilla.org/show_bug.cgi?id=382876

-- 
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde/attachments/20121117/1b4c1559/attachment.sig>
-------------- next part --------------
___________________________________________________
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.


More information about the kde mailing list