I haven't blogged about my involvement in KDE PIM in a while, so let's see what's new there, especially in the Google integration part....

Reborn Google Resources

Just before the KDE PIM sprint in Berlin this month, I've sat down and written completely new API for LibKGAPI (the library that implements Google API and is used by the Akonadi resources for Google services). The new API is job-based, and therefore much more awesome than the old one (which is known to suck). Anyway - what does this mean? It means that the new resources are awesome as well!

Google Contacts resource now has a full support for contacts groups. All contacts are stored in the top-level collection and are linked to the respective groups, so it does not matter where you edit the contact, you are still modifying the same instance. Like in the web interface.

Google Calendar now supports limited sync, so you can choose to only sync events from last year, or last two years (the default is last 3 years) instead of the full history.

Both resources have improved status reporting, error handling, are more stable (no more mystery crashes due to unhandled exceptions thrown from LibKGAPI) and subjectively synchronization is faster too.

Murdered Google Resources

As most of you probably noticed by now, Google is planning to shut down Google Reader by July 1. It's pitty, because I already had a fully working Akonadi resource for Google Reader ready in the akregator_port branch. Cost me lot of time and nerves. Well, the resource is not there anymore and the only memory of it is greader branch with API implementation in LibKGAPI (which will die as well sooner or later). The good news however is that I can now help Alessandro and Frank with ownCloud News and the ownCloud Akonadi resource, so that we rock when Akregator2 is out :-) I can't wait to see what has changed in ownCloud since I installed 3.0.0 some time ago...

Upcoming Google Resources

I have two feature requests in bugzilla: one is to support Google Bookmarks, which is fairly complicated because of missing official API and absolutely no write API. So this is not going to happen soon. The second feature request is for Google Drive KIO slave. This is much more interesting task. I already tried writing Google Docs KIO slave about three years ago and I failed epically. Retribution! There's almost complete API implementation by Andrius in LibKGAPI git, so I plan to port it to LibkGAPI2 and see whether we can together fight the Dark side and create a nice and shiny KIO slave.

Finally, deep in the dark corners of my mind, my so far the most evil plan is slowly shaping. The plan includes modifying the current IMAP resource, reusing most of it's code and subclassing some specific parts to build a native GMail Akonadi resource that would support some GMail-specific IMAP extensions. The main idea is to support one-mail-in-multiple-folders-at-once case. Right now the IMAP resource handles that by creating a new instance of the same email in multiple folders. My bold plan is to store all emails in Inbox and link them to respective folders. This means that marking an email as read in one folder, will automatically mark it as read in all other folders (because it's a single instance). The IMAP resource looks scary though, so I don't know yet when I'll get the courage (and time) to sit down and actually start coding...I guess probably after Akademy, after I talk to some people.

Batch Operations in Akonadi

I have talked to Volker Krause during the KDE PIM sprint about how to effectively handle "Mark feed as read" in the Google Reader resource. Currently, Akonadi creates a new notification for every change, therefore marking 300 items as read generates 300 notifications, which are delivered to the Akonadi resource, which should then create 300 HTTP request to store 300 changes. You probably agree that this slightly suboptimal. (I temporarily solved the problem by caching the notifications in the resource itself and then sending a big request to Google Reader at once). The solution that Volker suggested sounds fairly simple (it's not) - batch notifications - i.e. a single notification about single change involving multiple items. The supported changes can be flags change, deleting or linking of items. By being able to deliver single notification about mass-change to Akonadi clients and to Akonadi resources represents new possibilities for optimizations. For instance the IMAP resource could simply send a single command to add a flag to multiple emails at once, instead of doing it one by one. The same goes for other operations and other resources that are dealing regularly with operations on larger sets of items. The obvious result: performance boost! After two weeks the work is in semi-working state - it works, but it goes nuts if more than 5 items are involved. The cause is known, but solution not (but I'll get there eventually :-) )

Akregator 2

I'm occasionally helping with Akregator2 (Akonadi port of Akregator). Recently (ok, it was two months ago... ) I've written Akonadi Nepomuk Feeder plugin that is feeding RSS Articles into Nepomuk and a Search window (slightly inspired by the one in KMail) in Akregator2 where you can do full-text search (+ search via other criteria, including author's name and date of publishing) based on data indexed in Nepomuk. Obviously, when I wanted to demo that on the KDE PIM sprint I found out that it's not working as good as I thought, so there's still some work to be done. But in general I'm happy to say, that from time to time it finds something :-).

Ok, so that's about what I was, am and will be working on in KDE PIM. Here I'd like to say big thank you to all KDE PIM devs, because they are doing an incredible job. Thank you!

I've made a big progress with the upcoming libkgoogle 0.3 last weekend on the Fedora KDE SIG meetings which took place in Brno. I then decided to take some rest from all this Google things and wanted to relax by working on something else. But then I remembered that some time ago I experimentally implemented the Google Reader API and...well, see for yourself.

Originally I wanted to implement my own caching mechanism for the feeds, but I soon realized that I would be just wasting my time when there already is something as cool as  Akonadi.

I have written a simple Akonadi serializer for the data (took me about 20 minutes) and an Akonadi resource (that took me about 40 minutes to write). Finally I begun to write the client.

The client itself is very simple, it essentially only fetches list of streams (for those unfamiliar with Google's terminology, stream == RSS feed) and their content from Google Reader and is able to update 'read' flag of one or more items. You can't add or remove streams (maybe later).

Note: Do not try to "mark all as read" if you have too many unread items. The resource is sending a HTTP request for every single item (will be fix later, maybe...).

But hey, what's the difference between reading your feeds in a browser window or in a silly desktop client. To increase the level of (my) awesomeness I've made a Kontact plugin as well:

Btw, does anyone know how to change order of the items in the left pane? I'd like to have the reader where Akregator usually is :)

In the first sync, the resource fetches up to 200 latest items form each feed (I think that's a reasonable amount), then the updates are incremental. There is no progress indication, so just be patient.

In a way it is a "replacement" for Akregator  (but it lacks almost all of it's features :-), so actually it's not...). I suppose you don't need to have local feeds in an RSS client when you can interact with feeds on Google Reader directly. On the other hand, it's not a serious project, more like a preview or demonstration of power and awesomeness of the KDE technologies  (it's so simple to use Akonadi!) and all the people behind it. When libkgoogle 0.3 is out and stable, I'd like to dedicate some time to help with the Akregator port (if it's not finished until then), so this project will just rot in git, forgotten.

As I said, this is more of a tech preview, definitely not something for daily use. I won't be spending much time working on it, but of course, feel free to clone the repo (see below) and contribute.

How do I get this?

1) You have to use libkgoogle from the experimental "reader" branch. This branch is rebased against the development branch of what-will-become-0.3, so it's completely incompatible with the current resources from master branch.

$ cmake -DCMAKE_INSTALL_PREFIX=/usr/local -DBUILD_calendar=FALSE -DBUILD_contacts=FALSE

I recommend to install libkgoogle to some other prefix then /usr so that it does not conflict with the stable libkgoogle library, but if you feel brave enough, you can try to compile the branch with calendar and contacts resource as well, since they are mostly finished and working (and I would appreciate some feedback before releasing it).

2) Compile the Reader. The repository contains all the stuff - Akonadi serializer and resource, Kontact plugin, KGoogleReader KPart and KDEGoogleReader application (sorry for the KDEGoogleReader vs. KGoogleReader inconsistency, I couldn't decide how to name it so I was mixing both names :) )

$ git clone git://gitorious.org/kgooglereader/kgooglereader.git
$ cd kgooglereader
$ mkdir build && cd build
$ cmake ../ -DCMAKE_INSTALL_PREFIX=/usr -DLIBKGOOGLE_LIBRARY=/usr/local/lib/libkgoogle.so -DLIBKGOOGLE_INCLUDE_DIR=/usr/local/include/
$ make
$ make install #as root

Remember to replace the path to libkgoogle by wherever you have installed it. Now you should have kdegooglereader executable installed and when you restart Kontact you should see "Google Reader" in the left pane as well.

Well, I hope you like it :)