[Kde-pim] Still having trouble creating akonadi resource

[Volker Krause]

On Friday 02 January 2009 18:07:58 Stephen Kelly wrote:
> 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.

This also applies to IMAP, even more so as even the item IMAP UID changes 
during a move. Updateing the remote id is mandatory anyway then.

However, renaming a parent in the hierarchy is a problem with a backend that 
uses the name as a folder identifier (eg. every filesystem based backend). 
That would require an (otherwise not needed) update of the remote Ids of all 
children. Something we need to solve for eg. the maildir backend as well.

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

That's a very good idea. As you can probably tell, we don't have a best 
practice for all cases yet ;-)

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

The reason why the collection context is missing for all but the add signals 
is that we originally expected to use those signals within virtual 
collections as well. Which means that there could be more than one collection 
from which the same item was removed. Since we now have dedicated signals for 
link/unlink this probably doesn't hold anymore.

I've put the review of the whole change notification system on the agenda for 
the meeting next week, this obviously could use a bit more thought, 
especially now that we have actual users of this API.

> By the way, I have a bug in Monitor which finally made me dive deeper into
> the akonadi code. 

Unfortunately you picked one of its uglier parts there ;-)

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

Looks correct to me, please commit.

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/20090103/59bdc6c7/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/