[Kde-pim] Akonadi Commandline Interface Project

[Bhaskar Kandiyal]

On Friday 28 February 2014 10:47 PM, Jonathan Marten wrote:
> 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);
> 
Yeah, I thought about adding a "Are you sure you wish to do this? (Y/N)"
message but then I figured that would be inappropriate since the
akonadiclient is not supposed to be interactive.

> 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" :-)
> 
I was wondering what the ENV_VAR_DANGEROUS in the AbstractCommand class
was for, well, now I know, very well explained thanks a lot! :D

> 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.
> 
Thanks, I'll fix them up as you suggested.

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

I'm using Kubuntu 13.10 right now. Maybe I should install 4.12 from the
backports PPA. Thanks for the suggestion!

Cheers,
Bhaskar Kandiyal
_______________________________________________
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/