[Kde-pim] SoC 2008 project: RSS framework on top of Akonadi

[Dmitry Ivanov]

Hello,

I'm not sure if this is worth mentioning in a dot story but nonetheless 
I'm going to describe my SoC project and the work I've done and I'm asking 
for feedback/criticism.

This summer I've been working on a RSS framework on top of Akonadi. The 
framework is actually two-folded: an Akonadi RSS resource for fetching 
items from feeds and a library on top of the akonadi-kde library to 
provide convenient API for the user.

1. The RSS resource in fact slightly ignores the way a ResourceBase-
derived agent is supposed to work because:

 - it doesn't use CollectionSync and syncs collections on its own

 - it doesn't use the default ItemSync. Instead I've implemented a sync 
algorithm appropriate for RSS items by customizing ItemSync

 - it doesn't use ResourceBase::synchronizeCollection() (though it 
supports this method). The clients should use the custom D-Bus interface 
to trigger jobs to fetch/sync RSS items from different feeds concurrently.
And since the resource is capable of syncing a set of collections 
simultaneously it uses the aforementioned D-Bus interface to send progress 
info instead of AgentBase::progress().

So, you see that the Akonadi RSS resource breaks some assumptions how 
ResourceBase should work. The good thing is, it still stays under control 
of Akonadi :)

The resource can import/export OPMLv1/v2 subscriptions, fetch articles 
from feeds, store them in Akonadi, and it provides a convenient D-Bus 
interface for the users who don't want to link against the "user-space" 
library but would like to add/sync/remove a feed or two every now and 
then. Besides, the user can add/remove tags/subscription labels to feeds
but more about this below.

2. The "user-space" library provides convenient classes to manage 
feeds/items:

 - KJob-based API to add/modify/remove feeds and modify/remove items (RSS 
items aren't supposed to be created by clients). These jobs are actually 
wrappers around Akonadi jobs with some additional logic inside.

 - low-level classes to represent feeds, feedlists and RSS items. The 
library clients are free to show them in the GUI as they want (imagine an 
RSS plasmoid which shows articles but uses those cool looking Plasma 
widgets rather than plain boring view classes). The important thing here 
is that Akonadi RSS resources can co-exist but the library can merge them 
into a single feedlist (or show them as separate feedlists).

 - model/view classes to represent feedlists and item lists. Actually, it 
makes sense to put them in a separate UI library.

 - a standard action manager similar to StandardActionManager from 
akonadi-kde.

 - support for tagging feeds. By default tags are stored along with 
collections as attributes but I've implemented a Nepomuk tag provider so a 
basic integration with Nepomuk is there (though I think the support for 
NAO across Akonadi by default would be more useful).

 - support for per-application subscriptions. Applications which use this 
library can subscribe to feeds (the subscription labels are stored as 
collection attributes). So, in the nearest future you don't have to enter 
your favorite feeds in every RSS-enabled application you happen to use. 

 - in-memory virtual feeds. The library users can combine several feeds 
into a virtual feed that implements custom filtering, for example. Those 
feeds "live" only during the program run and thus are not sharable between 
applications. I managed to use in-memory virtual feeds to implement the 
quick search bar (like you now use in Akregator) with filtering going in a 
dedicated QThread (no blocking UI). It was pretty easy, though there are 
still some issues to sort out.
Unfortunately, I couldn't implement persistent (ie. on-disk/sharable) 
virtual feeds as there was no support for some features in Akonadi. But 
now as the required bits are implemented I'll be able to finish my work 
there. 
This virtual feeds hierarchy is still debatable since it complicates the 
API.

There is a simple application in playground/pim (KRssReader) which shows 
off some of the library aspects but it is really basic. One can write their 
own RSS reader in 10 minutes (after they spend 10 minutes writing a mail 
client, of course :)

As for my future plans:

1. Add support for persistent virtual feeds. This is something that the 
users of Akregator have been waiting for a long time.

2. Refactor the RSS resource and create a generic RSS Akonadi resource so 
users/developers can easily implement custom RSS backends. For example, a 
RSS resource that represents info from an Openchange server as RSS items 
(I remember I talked to Brad Hards about this, but I may confuse some 
terms/principles here). Or a dedicated RSS resource to sync feeds and 
items via the Newsgator.com online feed reader (or Google reader).

3. And the ultimate goal of the project is to get these things up and 
running on maemo so I can finally read articles everywhere and sync them 
via newsgator.com. (NG.com support for Akregator was actually my initial 
proposal for SoC but we turned it down due to various reasons).

All in all, SoC was fun and productive (I've learned lots of things). I 
have already provided some feedback regarding Akonadi which hopefully was 
discussed at Akademy.

But now I should concentrate on my PhD (debugging a wireless mesh network 
in a network simulator is not fun :/ ) until the middle of September 
(papers and presentations). But after that period I'm back. The future of 
Akregator and this framework is still under discussion.

Dmitry

-- 
A: Because it destroys the flow of the conversation
Q: Why is top-posting bad?
_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/