Most of the time I've been working on Akonadi support for a KMail mail store, basically a local directory where mails are stored in a combination of nested Maildir directories and MBox files.
Conceptionally my preference would have been an import process, but of course factors like requiring (at least temporarily) close to twice the storage space, make the direct usage more viable for the upcoming releases.
So after a couple of days of feverish hacking, we've now got a "Mixed Maildir" resource, capable of operating on a local folder tree created by KMail, including read-only support for message flags ("read", important", etc.).
Today I wanted to work on something different, so I started with an idea I had when brainstorming for possible GSOC/SOK ideas.
Akonadi is service based infrastructure, so there is a bunch of processes working together to satisfy the users' PIM needs.
While it is of course possible to show the status of e.g. resource for a specific data type in the applications handling that data type, say showing status of IMAP resources in KMail, there are use cases for having access to that information even when non of these applications are running.
Probably the best way to do that on a KDE Plasma Desktop Workspace is to have our status information available through a Plasma Data Engine. So I created one:
Akonadi Agents can be controlled through their D-Bus interfaces, e.g. asked to show their configuration UI or in the case of resource agents (data connectors) to (re-)fetch data from their respective backends.
Plasma has matching technology for this use case a well, Plasma Services. So I created one of these as well:
So the obviously missing piece is a Plasma Widget for actually displaying the data and providing the action UI for the service.