View source for Documentation/CLI In Context

This page lists some example and notes on different integration of CLI modules in different frameworks including CTK (see [[Documentation/Command_Line_Interface]]). The first interoperability testing was done during the [http://www.creatis.insa-lyon.fr/Interoperability_workshop third] VPH NoE Imaging workshop hold in Lyon, France on October 22-23, 2012. It will be continued in consecutive hackfests. The aim is to try to plug in CLI modules in CLI compatible frameworks and come up with possible improvement of the CLI standard, advice to CLI module and CLI framework developers.

== Events ==

* [[CTK-Hackfest-Nov-2011|CTK Hackfest]] in Sophia Antipolis, France in November 2011
** Preliminary work to integrate CLI into Gimias
* [[CTK-Hackfest-Jul-2012|CTK Hackfest]] in Boston, USA in July 2012
** Preliminary work to integrate CLI into MITK
* [http://www.creatis.insa-lyon.fr/Interoperability_workshop 3rd VPH NoE Imaging workshop] in Lyon, France on October 22-23, 2012
** First [[#Interoperability_tests|Interoperability tests]] with CTK, Gimias, NiftyView and Slicer
* [[CTK-Hackfest-Dec-2012|CTK Hackfest]] in Bologna, Italy on December, 2012
** Preliminary work to integrate CLI into medInria, MAF3
** Semi-Automatic framework CLI integration tests

== Interoperability tests ==

These first tests mainly concern the integration of niftyreg (registration algorithms from UCL). The different stages of integration are: load, execute and results. Meaning that the CLI module can be loaded. executed and provides the same results as if it was run only from the command line. The problems we encountered were:

* Gimias does not support to have a `default` element different that `None` for the output, not sure about the `advanced` option for the `parameters` element 
* niftyreg was using `fileExtensions` with stars (`*.nii`) which is not supported by neither Gimias nor Slicer (the star is directly used in the file name)
* The default output folder should be set to the user folder and not the running one, otherwise the CLI module can crash because they were denied access to write in that folder (for example `Program Files` under Windows)
* What to do with CLI modules that have dependencies on shared libraries with the platform but of different versions? Platforms should have the option to only use the libraries shipped with the CLI module
* Platforms should align the way they treat data since if two load data differently, the same CLI module could give different results

It would be interesting to create test CLI modules for these integration tests. For example one that exposes all possible types of options, one running a simple algorithm without any dependencies (as niftyreg) and one with dependencies.

Some thoughts on the tested platforms:
* Niftyview has nice controls on the way CLI modules are found and loaded (control on the `XML` validation)
* Slicer has a nice display of the loaded and non loaded CLI modules (appear in red, there could be more explanation why the loading failed)

== Snapshots ==

Here are the snapshots of niftyreg on the different platforms:

* CTK command line module explorer 

[[File:Niftyreg-ctk.png|400px]]

* Slicer

[[File:Niftyreg-slicer.png|400px]]

* NiftyView

[[File:Niftyreg-niftyview.png|400px]]

* GIMIAS 

[[File:Niftyreg-gimias.png|400px]]


* medInria

[[File:medinria-cli-niftyreg.png|400px]]