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

[Volker Krause]

On Tuesday 02 September 2008 21:33:07 Dmitry Ivanov wrote:
> 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 :)

Excellent work!

> 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.

That was very valuable indeed, especially since you used the resource stuff in 
a way it was never designed for ;-)

regards
Volker


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20080906/96f31cf1/attachment.sig>
-------------- next part --------------
_______________________________________________
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/