[Kde-pim] libakonadi-kde API questions

[Volker Krause]

On Friday 28 March 2008 22:47:28 Tobias Koenig wrote:
> although we had a lot of discussion in Berlin last weekend, there are
> some small issues left with the API that need some further discussion:
>
> 1) The CollectionPathResolver is a private class now, unfortunately the
>    'akonadi' client application in kdepim/akonadi/clients makes use of it,
>     so I had to install the header file to
> <akonadi/private/collectionpathresolver_p.h>
>
>     Any idea how to fix that? Is there a way to replace that functionality
>     in 'akonadi'?

Hm, I think this class is essential for command line tools. But since there 
are probably no use cases apart from that, we probably can move it there.

> 2) The types (e.g. Virtual, Folder, Resource etc.) in Collection should
>    be dropped, however there is some code that still relies on them.
>    How to port that?

These types are determined by very simple checks in CollectionFetchJob (I 
think), we probably can use those directly where needed.

> 3) The ItemModifyJob::setCollection() is only marked as deprecated, I
>    guess that's because ItemSync still uses this job type instead of
>    ItemMoveJob since it needs the storePayload() method?
>    Can that be ported somehow?

I'm working on that already.

> 4) The Monitor has the methods
> 'monitorItem/Collection/Resource/MimeType/All()' and we decided to add the
> methods 'unmonitorItem/...()'.
>    However the word 'unmonitor' doesn't exists, so we should come up
>    with something else. Aaron said that 'ignore' would be the
>    counterpart of 'monitor', however ignoreItem() could be misleading
>    here. Another propose was: monitorItem( Item, bool = true ).
>    What do you think?

Just for the record: IRC discussion earlier today resulted in setFooMonitored( 
const Foo &foo, bool = true ) as suggested by Till.

> 5) ItemSync currently has two setter methods where only one of the
>    setter should be used for one object.
>    The normal way to enforce that (and to be consistent with the other
>    jobs), the ctor should take these values as additional arguments.
>    However we'd have a ctor with 4 arguments then, too many IMHO.
>    Any ideas?

Since ItemSync is a special case some differences to the normal jobs seem 
acceptable. Enforcing correct usage could also be done by asserts then.

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