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

[Volker Krause]

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

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

> 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
-------------- 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/20080612/11a0a23d/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/