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
Attachment:
signature.asc
Description: This is a digitally signed message 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.
