[Kde-pim] Akonadi Commandline Interface Project

Jonathan Marten jjm2 at keelhaul.demon.co.uk
Fri Feb 28 17:17:23 GMT 2014


Hello Bhaskar,

Bhaskar Kandiyal <bkandiyal at gmail.com> writes:
> I've been working towards getting familiar with the existing code of
> akonadiclient. I added a few commands to the existing client just to get
> the hang of it. The commands are as follows:
>
> * Clear - Clears all items of a collection
> * Export - Export collection to an XML file
> * Import - Import collection from an XML file

Looks good as a start.  I'm not familiar with the Akonadi XML
interface, so I'll leave it to any others who may want to comment on
that.  For the Clear command, just some things that I've noticed from
a quick look though the code:

This is a dangerous command (extremely so!).  So as to avoid any user
prompting for confirmation (which is not so useful for command line
scripting), there is a check for such commands which needs a magic
variable to be set in the environment in order to be able to execute
such commands.  So, in ClearCommand::start(), the first line should
be:

   if (!allowDangerousOperation()) emit finished(RuntimeError);

AbstractCommand::allowDangerousOperation() does the actual check.  If
you run the command without the env variable set, it will fail and say
what needs to be done.

It's up to each individual command to decide whether they are
dangerous or not, but the reasoning that I've followed so far is that
any operation which involves deleting any items or collections (even
if they are being saved or moved elsewhere) is dangerous.

Obviosuly this environment variable can be set and then forgotten in
any command script which needs to perform these operations, so it
isn't completely foolproof - but it was intended to avoid the
situation where someone just experimenting in the shell thinks "hmmm,
wonder what this does... let's try it... oops, didn't mean to do that" :-)

You may want to create the CollectionResolveJob in
ClearCommand::initCommand(), and check that it hasUsableInput().  This
will give better error reporting if the collection syntax is bad.  You
don't need to connect signals or start() the job until
ClearCommand::start(), though.  Also, check for job->error() and
report it at the start of ClearCommand::onCollectionFetched().  See,
for example, copycommand.cpp for the typical syntax checking and
collection resolving sequence.

> For the Export functionality I used the Akonadi::XmlWriteJob, but
>since this class isn't available in pre-KDE 4.12 so to make it work
>for me on KDE 4.11 I had to include the source for Akonadi::XmlReader
>and Akonadi::XmlWriter in the akonadiclient. I don't know if it's the
>best way to do this though.

If you eventually want your code to be in KDE (and we do, of course),
then you will need to target the current version so there will be no
need for the copy.  I don't know what distro you have or whether it is
practical for you to compile KDE from source, but hopefully by the
time summer comes you will be able to upgrade to a later base.

Best 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/



More information about the kde-pim mailing list