[Kde-pim] Still having trouble creating akonadi resource

[Stephen Kelly]

Volker Krause wrote:

> On Monday 29 December 2008 18:08:02 Stephen Kelly wrote:
>> >
>> > 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 think I saw the code that does that in server/src/storage/datastore.cpp.
More on that stuff in a later email.

>>
>> I see, is this a missing feature that will be added, 4.3 material? Is it
>> simple enough that I can add it myself?
> 
> Yes, I see that as 4.3 material. It is very similar to the other Observer
> methods, the tricky part is keeping BC.

I've got a non BC solution as a proof of concept. More on that coming later
too so we can figure out how to make it BC.
 
> IMAP and NNTP use remoteId as a URL containing a path to the item, with
> every parent folder being identified by its remote id. This maps nicely in
> this case since that's more or less how these protocols work anyway.

Using the full path will break in several cases. Say you have two imap
folders 'foo' and 'bar' whose parent is 'collection::root', and
another 'bat' whose parent is 'foo'.

The remote ids will be 'foo', 'bar' and 'foo/bat'. An item in bat will have
the remoteId 'foo/bat/item1'.

If you then move the bat collection from 'foo' to 'bar', suddenly the
remoteId for item1 is wrong. It would need to be changed
to 'bar/bat/item1', right? I don't know if there's a sensible way to keep
that kind of thing up to date. It's not as much of a problem if the
remoteId only knows its parent, but not grandparent or greater. Still it
would need to be kept up to date, and that could get messy. I think the
best solution is for remoteIds to not have any information about their
parents.

You can probably tell I'm trying to encode some best practices on how to use
the akonadi library.

> 
>> 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.
> 
> Right, that's an oversight in the API, both should be added.

While we're changing API, collectionRemoved and itemRemoved need to know
what collection they were removed from. That would take away any need for
resources to maintain a hash of parents as the kjots one currently tries to
do. That's a messy thing to manage that we could do without.

By the way, I have a bug in Monitor which finally made me dive deeper into
the akonadi code. It doesn't correctly emit the itemMoved signal. The
destination collection is not really there in the signal.

To reproduce, get the latest kjotsrewrite, add the resource, and start the
app. Then move an item from one collection to the other, giving debug
output like this:

kjotsrewrite(25788) Akonadi::EntityTreeModelPrivate::itemMoved:
item.remoteId= "foo.kjpage" sourceCollectionRemoteId= "foo.kjbook"
destCollectionRemoteId= "" destCollectionId= 88 

Notice destCollectionRemoteId is empty, but destCollectionId is correct.

Then apply the attached patch, and do it again. The collection is retrieved
and destCollectionRemoteId is correct.

Can I commit?

regards,

Steve.

> 
> regards
> Volker

-------------- next part --------------
A non-text attachment was scrubbed...
Name: fixitemmovedsignal.patch
Type: text/x-diff
Size: 4043 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20090102/6890a54e/attachment.patch>
-------------- 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/