[Kde-pim] [GSOC] AkonadiClient Commands

[Bhaskar Kandiyal]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 05/06/2014 02:18 PM, Daniel Vrátil wrote:
> 
> 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 :-)

The reason for having a --force option was to not let users
accidentally run the command and perform an unwanted delete operation.
The current implementation uses an environment variable which needs to
be set to allow dangerous operations like "delete" which could still
result in an accidental delete if the user forgets to unset the
environment variable. Maybe we can rename "--force" to something else?

> 
> * 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.
> 
There are options for specifying an item or a collection in the
current implementation of the 'info' command.

> * "create <collection>" should probably be under filesystem
> commands?
> 
Ah, yes, I don't know why I added it in the data commands, thanks :)

> * 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".
> 
setOffline and setOnline sounds good.

> * 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?
> 
The import/export commands use XML to import / export collections and
items. The 'add' command is for raw payload.

> * 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 ;-)
> 
The main purpose of this tool is to provide advanced users and system
administrators a means to perform automated tasks (through shell
scripts) on Akonadi's data.

Not sure what I was thinking when I added the query command, I guess I
thought of it as a way to easily give users direct access to Akonadi's
database and executing queries manually if need be. But I agree it can
be dangerous. I'll remove it :)

> 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)
> 
> 
Awesome! I'll add these commands to the document as well.

Many thanks for the comments and suggestions, much appreciated :)

Cheers,
Bhaskar Kandiyal
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iEYEARECAAYFAlNpLaYACgkQc3l9wn9I2Oc/LwCfWylz7l2keaTmky3x3RRFdsAn
HJ4AoLe1uk1hN8JANGi0oURoI2Lz/B9d
=cL/r
-----END PGP SIGNATURE-----
_______________________________________________
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/