[Kde-pim] Still having trouble creating akonadi resource

[Volker Krause]

On Monday 29 December 2008 00:45:12 Stephen Kelly wrote:
> The biggest problems I have right now are in the resource code and mainly
> caused by not knowing the parent collection at various times when trying to
> update harddisk stored data and things like that.

The idea is to use the remote id for this, as a kind of path, if those ids are 
required in the resource. At least that is what other complex resources 
(IMAP, NNTP) do so far.

> When I move an item from one collection to another with an itemmovejob, the
> resource seems to get two notifications. It gets a collectionChanged for
> the source, and the destination collection. However, as a collection
> doesn't know its items, I don't think I can figure out in the
> Resource::collectionChanged slot that an item move has occurred and modify
> on-disk files. I don't know how I can get around this. Possibly an
> itemCopyJob and a ItemDeleteJob in a transaction? I don't think that's a
> very good solution.

The problem seems to be that AgentBase::Observer misses a method for the 
itemMoved() signal (which Monitor already has). Still, the 
collectionChanged() signals seem wrong here.

> Also, a Hash of parents for entities is maintained in the resource. This is
> because Items don't know their parent. Additionally, I've found that
> collection::parentRemoteId always returns an empty string from the
> collection passed into the slot. So the hash is used there too. I'm not
> sure if that's a bug, or I need to set something monitored in the change
> recorder. The problem with this approach is that when a collection is moved
> to a different parent, that corresponds to a collectionChanged for that
> moved collection. However, the parentRemoteId in the hash in the resource
> is still the previous parent. I can use that to figure out where the
> collection should be moved from, but I can't know where it should be moved
> to. Possibly this would be solved if Collection::parentRemoteId worked.

As the API docs note already, parentRemoteId() will return an empty string in 
most cases, it is only used for building the collection tree on delivery from 
the resource.

The reason why Akonadi objects don't have a convenient parent() method is that 
this would require to have the full collection tree in memory on the client 
side or using sync jobs in that method to download the parent object. As 
noted above, encoding essential information into the remote id is one way to 
work around this and avoid maintaining your own parent mapping.

> The whole idea of storing data in this resource in up for change if there's
> a way that will work better with akonadi by the way.
>
>
> Nothing at all is set in stone yet because I'm still hitting large brick
> walls with this stuff. I know I'll have to refactor it again anyway. I
> still get the impression I'm using akonadi the wrong way here.

I wouldn't say in a wrong way but certainly in ways that were not considered 
from the start and are not common for the other types:
- the limitation to one local resource (this takes out about half of the 
reasons for using Akonadi, making the port extra tedious compared to the 
gain)
- the ordered storage of pages and books
- the mixed item/collection view

regards
Volker
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20081229/213c06b1/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/