[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-pim
Subject: Re: [Kde-pim] libakonadi-kde API questions
From: Volker Krause <vkrause () kde ! org>
Date: 2008-03-29 16:33:42
Message-ID: 200803291733.43343.vkrause () kde ! org
[Download RAW message or body]
[Attachment #2 (multipart/signed)]
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
["signature.asc" (application/pgp-signature)]
_______________________________________________
KDE PIM mailing list kde-pim@kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic