I saw a snippet recently pointing to a concern about data fragmentation relating to Akonadi.
After talking with doctormo about it, the concern seems to be that there are a lot of services and applications trying to be the single standard point of access for PIM data.
From my standpoint (biased obviously) I don’t think it is a relevant issue for Akonadi using applications, because Akonadi is designed exactly to deal with the data fragmentation issue, by consuming PIM from other locations. For example, contact details from pidgin can now be made accessible in KAddressBook:
Here’s how that happened:
After digging around I found that Elementary is an Ubuntu derivative which is making some new applications, such as postler, an email application. I couldn’t find any ‘backend’ for postler. It seems to talk directly to dexter, the addressbook application. If the two applications catch on, that would be additional places that your data would exist or need to be copied and possibly get out of sync, and could mean that dexter must be running in order for postler to have access to addressees. I couldn’t find a SCM repo to check if that is the case.
Postler and dexter don’t use evolution-data-server as a backend either, preferring to avoid it for whatever reason. Akonadi was likely never considered by the postler developers because they might think it depends on something fictional like the KDE desktop environment, which is clearly not the case. The point is though that non-adoption of common infrastructures between different applications is usually a social, communication and perception problem, but not a technical one. That can lead to the kinds of data fragmentation and inter-application dependencies which we saw between KDE 3 applications and which appear to exist between postler and dexter.
Those who have followed Akonadi development will know that PIM applications in KDE PIM 4.6.x do not own the data they show. KAddressBook does not need to be running or even installed in order for KMail or KOrganizer to access contact information for people. The reason is of course that KAddressBook does not own the data. Even Akonadi does not own it, but just provides access to it from third party data providers.
This is the primary distinction between data syncing between applications and data sourcing by applications. Syncing requires that one-to-one copies be made (and kept up to date) of ‘shared’ data between collaborating applications, possibly between differing formats or data representations and different transport mechanisms. However shared data allows many-to-many relations where all applications can access all data with zero knowledge of the other applications. Because no application owns the data, there is less work needed to prevent them getting out of sync with each other.
Akonadi is designed to address the problem of data fragmentation, by knowing the various sources of PIM data, and making all of it available to applications. The applications don’t need to know where Akonadi gets the data from. It only needs to get it from Akonadi and not concern itself with the true origin.
This means that if it came to it and people wanted to share data between dexter and Akonadi based applications, it would be possible. A somewhat more interesting project, for various reasons, from the GObject side at the moment is folks. Folks is designed to aggregate information about individual people between multiple different applications, comparable to the PIMO::Person concept KDE people might be more familiar with.
There are Qt bindings currently under parallel development with the GLib/QObject based library, which means that if PIM data from Gtk or GNOME based applications are made available to folks, making that same data available to KDE applications is as simple as writing a new Akonadi resource for it.
Because the Qt bindings implement the QtContacts API, a generic Akonadi resource for that API works for any implementation of it. So even the Akonadi backend for folks doesn’t have any direct knowledge of the folks system. I created a proof of concept for exactly that this week, allowing to access contacts from pidgin in KAddressBook. With the roadmap for Qt-folks, it could become more useful for data sharing going forward.
Thanks to Martin and to Travis for reviewing this post and providing feedback.