[Kde-pim] [GSOC] AkonadiClient Commands

[Jonathan Marten]

Daniel Vrátil <dvratil at redhat.com> writes:
> On Sunday 04 of May 2014 23:43:15 Bhaskar Kandiyal wrote:
>
> couple comments from me:

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

I've thought about this ambiguity before, but have not got around to
implementing a solution.  Currently the 'info' command implements
options '-i' and '-c' to explicitly specify whether a plain number is
to be interpreted as an item or collection ID, but it's a clumsy way
and it means that every command that can take either an
item or collection has to implement these options.

A better solution, by analogy with C++ number syntax, would be to add
a suffix - for example, "1334i" (case insensitive of course) would
mean an item while "1334c" would mean a collection. A number without a
suffix would mean whatever was appropriate if only an item or
collection would be valid (e.g. the argument for 'list' is always a
collection), otherwise it could be rejected as ambiguous. Named
collections have to start at the root*, so there can be no ambiguity
between either of those and a collection named "1334c" (which would
have to be entered as "/1334c".

[*] Unless we implement a "command loop" when invoked without
arguments, such as in xauth, lpc or the Perl CPAN shell.  With this
persistence there can be the concept of a "current collection" and a
cd command to move around.  Then a plain number could potentially have
three interpretations, and there would have to be a notation to
distinguish between 'a subcollection of the current collection named
"1334"' and 'the collection with ID 1334'.

> * 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 ;-)

I'd agree with this.  If a developer really wants to script and
execute raw SQL on the database, then they may as well use mysql
directly.  The only point in having an "SQL forwarder" in
akonadiclient would be to abstract away details of the database
backend and configuration, but any SQL would likely be
database-specific anyway.

> * 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?
>
> * 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?

For 'add' it is currently the raw payload (auto detected MIME type).
The import/export commands that Bhaskar has already prototyped use
XML.

> 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 ;-)

This is already possible with the '-c' and '-l' options to the 'list'
command - which is a different interpretation of the same options for
the 'info' command, another good reason for not using them for
item/collection disambiguation as above :-)

Regards, Jonathan


-- 
Jonathan Marten                         http://www.keelhaul.demon.co.uk
Twickenham, UK                          jjm2 at keelhaul.demon.co.uk
_______________________________________________
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/