[Kde-pim] Still having trouble creating akonadi resource

[Volker Krause]

On Monday 29 December 2008 18:08:02 Stephen Kelly wrote:
> 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?

Yes, I see that as 4.3 material. It is very similar to the other Observer 
methods, the tricky part is keeping BC.

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

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.

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

> >> 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
-------------- 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/20081231/e09c7fc3/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/