[Kde-pim] [GSOC] AkonadiClient Commands

[Daniel Vrátil]

On Sunday 04 of May 2014 23:43:15 Bhaskar Kandiyal wrote:
> Hi,
> 
> My first task in the proposed timeline for my GSOC 2014 project was to
> study the existing prototype, gather use cases and formalize the
> commands to be implemented based on those gathered use cases.
> 
> I have compiled a list of commands [1] that need to be implemented in
> the Akonadi client.
> 
> Any comments or suggestions are welcome :)

Hi,

couple comments from me:

* I would remove the --force option from "delete" command. --force is usually 
used to bypass some checks that would otherwise prevent the action (like 
overwrite existing changes for example), you are using it the other way around 
:-)

* How do you differentiate between item and collection? If I do "akonadiclient 
delete 15", is that a Collection, or an Item? Collections and Item IDs can 
overlap. Same for "move" i suppose.

* "create <collection>" should probably be under filesystem commands?

* agent offline|online <agent-id> - maybe call these setOffline setOnline? 
Other methods (list, info) are used to get information, so "online"  sounds 
like "oh, this tells me whether the agent is online or not".

* I'm not sure what's the difference between "add" and "import" ? Both take a 
file and add it to a Collection (parent). The only difference I can see is 
that "add" can work with multiple files, but then "import" is just crippled 
"add" and is not needed?

* What is the purpose/use case for this tool? (Sorry, I don't know your GSOC 
proposal) Unless it's supposed to be a developer tool, having an option to 
query the SQL backend is a bad move IMO. The fact that Akonadi is using a 
database is an implementation detail that should not be exposed to users in 
any way.  Executing SQL queries on the database (unless you really know what 
you are doing) can be dangerous, and we have Akonadi Console for doing 
dangerous crazy things with Akonadi ;-)

* A general question: what is format of the files that "add" or "import" 
expects? Is it a defined XML format, or just the raw payload? In that case you 
probably want to be able to specify additional attributes, or multiple payload 
parts?




And so that you don't say I just criticize, some more ideas you could add :-)

* list only collections - sometimes it might be useful to get only the tree 
hierarchy of collections, without the items

* list only items in a collection - sometimes you don't care about 
subcollections ;-)

* tagging
	- list of tags
	- create/rename/remove tag
	- assign a tag to an item

* export of individual items in XML

* search <query> - Executes a <query> and returns list of items matching the 
result (see Akonadi::ItemSearchJob and Akonadi::SearchQuery)


Cheers,
Dan


> 
> Cheers,
> Bhaskar Kandiyal
> 
> [1] -
> https://docs.google.com/document/d/16MrsQKx7YjfzgPb41r2j8_lSQhZqq2UsEXXpcKyh
> 26s/edit?usp=sharing
-- 
Daniel Vrátil | dvratil at redhat.com | dvratil on #kde-devel, #kontact, #akonadi
KDE Desktop Team
Associate Software Engineer, Red Hat, Inc.

GPG Key: 0xC59D614F6F4AE348
Fingerprint: 4EC1 86E3 C54E 0B39 5FDD B5FB C59D 614F 6F4A E348
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20140506/dfd1c81e/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/