[Kde-pim] Still having trouble creating akonadi resource

[Stephen Kelly]

Volker Krause wrote:

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

Yes, I am reconsidering refactoring the resource to work like this too.

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

I see, is this a missing feature that will be added, 4.3 material? Is it
simple enough that I can add it myself?

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

Right, sorry, didn't notice that in there in the docs.

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

I see (I think :)). However, I am limited in what information I can encode
into the remoteId. I can't put the id() of anything in there. I could put
the parent remoteId, or all ancestors into it, but that's only as good as
the Hash that I am currently using. I still would have the issue of not
knowing both the source and destination when a collection is moved.

However, itemMoved(Item, Collection src, Collection dest);, and
collectionMoved(Col, Collection src, Collection dest); in the observer
would make this problem go away.


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

Yes, I'm beginning to see the light here. That will be changed.

> - the ordered storage of pages and books

Shouldn't be too much of a problem. It works on the model side, only the
resource side is problematic, but changes to the observer would make it
simple.

> - the mixed item/collection view

That's working quite well now for the most part, but there is lots more to
do.

> 
> regards
> Volker

Thanks for the help,

Steve.


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