[Kde-pim] Push changes to Akonadi from inside a resource

[Dmitry Ivanov]

On Friday 13 June 2008 01:22:58 Volker Krause wrote:
> On Wednesday 11 June 2008 10:46:31 Dmitry Ivanov wrote:
> > To make the RSS framework more flexible we decided to add a D-Bus
> > interface to the RSS resource to allow applications to manage feed list
> > (i.e. add/remove feeds) via D-Bus calls as well as the usual itemview
> > models. Resources are
> > supposed to be Akonadi-driven (at least I got such impression) and I need
> > to make the RSS resoure behave like an asynchronous resource.
> >
> > While trying to tie D-Bus and the resource together (it turned out to be
> > quite easy) I discovered  that there are more than one way to _push_ the
> > changes to Akonadi from inside the resource.
> >
> > 1. When a new feed gets added via D-Bus I call
> > synchronizeCollectionTree() from inside the resource which leads to
> > retrieveCollections() and finally to collectionsRetrieved(). Akonadi
> > syncs the collection tree and picks up the new feed.
> >
> > The advantage of this way is that the new collection (and its parent
> > collection) needs to have only the remoteID properly set (at least from
> > what I've seen so far).
>
> ...and the parent remote id, but you are right, the resource (or to be
> precise the CollectionSync class) resolves remote ids automatically.
>
> > The main disadvantage is that Akonadi has to refetch the entire
> > collection tree from the resource and then check if there are changes in
> > it (if I understand it correctly).
>
> That's correct if you call collectionsRetrieved() to deliver the
> collections. However, there is also collectionsRetrievedIncremental() which
> is a lot more efficient but requires that you know which collections have
> been
> added/updated or deleted (which seems possible given you get these changes
> explicitly via the D-Bus interface).

Oh, It seems incremental retrieval is exactly what I need. Thanks for the 
hint.

>
> > 2. When a new feed gets added via D-Bus I can use CollectionCreateJob to
> > push this feed to Akonadi. This triggers the collectionAdded() event
> > which is also invoked after adding a new collection via itemviews.
> >
> > The advantage of this method is that the resource handles new feeds in
> > a unified way via collectionAdded() and Akonadi doesn't need to refetch
> > the entire collection tree, only the new collection.
>
> Actually, collectionAdded() shouldn't be called for changes done by the
> resource itself (at least the change monitor blocks those by default).

I was not going to call it explicitly, but it would be called automatically 
after CollectionCreateJob().

>
> > The disadvantage is, the root resource collection has to have the ID
> > properly set. Otherwise CollectionCreateJob appends the new feed to the
> > root Akonadi collection (i.e. in case I pass a collection with id < 0 to
> > CollectionCreateJob as the parent collection). To meet this requirement I
> > have to use
> > CollectionFetchJob to fetch the root resource collection after the user
> > imports his subscriptions via resource config dialog. (when the user
> > imports subscriptions
> > the resource builds the collection tree but the collections have invalid
> > IDs, obviously).
> > Probably I could create the root collection when the resource starts for
> > the first time and then fetch it from Akonadi after every restart. I
> > need to check
> > it.
>
> Right, I guess we eventually need a third way ;-) So far we don't have a
> convenient way to push changes for resources that get explicit change
> notifications from the backend, mostly due to the lack of such a backend.
> Initially we thought that using the jobs directly would be enough in that
> case, but those lack automatic remote id resolution as you noted.
>
> > So the question is, which method of pushing changes to Akonadi from a
> > resource is more appropriate (if they are correct at all)? Currently, I
> > prefer 1) because it was
> > easier to implement. Maybe there are pitfalls I don't see?
>
> regards
> Volker

Dmitry
_______________________________________________
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/