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

[Volker Krause]

On Friday 13 June 2008 08:40:41 Dmitry Ivanov wrote:
> 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.

Great :)

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

That's what I meant as well, it will not be called by default for changes done 
by the resource itself, including if the resource runs a CollectionCreateJob. 
It's connected to the signals of a ChangeRecorder which is configured to only 
monitor changes to objects owned by the current resource done by anyone but 
the current resource to avoid notification/update loops. This can be changed 
by the resource however if needed.

> > > 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/20080614/194c65cb/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/