Documentation/Labs/SlicerBridge - Revision history

Pieper: /* Motivation */

2016-01-26T16:21:50Z

Motivation

Pieper: /* Concept */

2016-01-26T16:20:48Z

Concept

Pieper at 16:17, 26 January 2016

2016-01-26T16:17:04Z

Pieper: Created page with "==Motivation== At the past several project weeks and in developer discussions we have revisited the questions about which python packages should be included in Slicer core...."

2016-01-26T16:14:01Z

Created page with "==Motivation== At the past several project weeks and in developer discussions we have revisited the questions about which python packages should be included in Slicer core...."

New page

==Motivation==

At the past several project weeks and in developer discussions we have revisited the questions about which python packages should be included in Slicer core.

Building Slicer with anaconda / miniconda has been evaluated but certain practical issues remain about relying on external binaries and resolving version issues (e.g. the conda-provided VTK could not be used with the Slicer provided VTK).

Rather than dive deep into porting python build systems and supporting them inside Slicer maybe there's a better way...?

==Concept==

The SlicerBridge concept builds on the success with the MATLABBridge extension already existing in Slicer. The idea is to treat anaconda in the same way we treat MATLAB, as an external process with a well defined interface for passing data and invoking remote computation.

In practice this could be as simple as a module launching the anaconda-based process and then connecting to it via OpenIGTLink.

Benefits of this approach:
* An external process could use anaconda or in fact any language so long as it implements the interface.
* The external process could be on another machine, allowing division of labor between visualization and computing. In fact multiple processing machines or clusters of computers could use the same mechanism to attach.
* The external processes can provide self-contained functionality useful in other contexts outside of Slicer, such as headless batch computing.
* The external process could be run inside a docker container or other virtualization method. This could allow such things as running windows-only extensions with a linux front-end or vise versa.

==Implementation Options==

* Could build out on the existing MATLABBridge infrastructure using OpenIGTLink
* Could use zmq and the iPython kernels as used in clustering for iPython
* Could use WebSockets and/or HTTP

==Current Status / Discussion==

A few developers have started discussing this but no concrete action has been taken yet.

Some open questions include:
* What guidelines for developing code that would work cleanly in this environment?
* Which technologies will best implement this strategy and how can we best leverage developments in the wider developer community.
* Are there extensions to the OpenIGTLink protocol that would make this even more powerful and useful?

@@ Line 3: / Line 3: @@
 At the past several project weeks and in developer discussions we have revisited the questions about which python packages should be included in Slicer core.
-[[{{FULLPAGENAME}}/PythonCondaBuild|Building Slicer with anaconda / miniconda]] has been evaluated but certain practical issues remain about relying on external binaries and resolving version issues (e.g. the conda-provided VTK could not be used with the Slicer provided VTK).
+[[Documentation/Labs/PythonCondaBuild|Building Slicer with anaconda / miniconda]] has been evaluated but certain practical issues remain about relying on external binaries and resolving version issues (e.g. the conda-provided VTK could not be used with the Slicer provided VTK).
 Rather than dive deep into porting python build systems and supporting them inside Slicer maybe there's a better way...?

@@ Line 14: / Line 14: @@
 Benefits of this approach:
-* An external process could use anaconda or in fact any language so long as it implements the interface.
+* An external process could use anaconda or in fact any language so long as it implements the interface.  External processes can use different python versions and packages than each other and different than Slicer.
 * The external process could be on another machine, allowing division of labor between visualization and computing.  In fact multiple processing machines or clusters of computers could use the same mechanism to attach.
 * The external processes can provide self-contained functionality useful in other contexts outside of Slicer, such as headless batch computing.
 * The external process could be run inside a docker container or other virtualization method.  This could allow such things as running windows-only extensions with a linux front-end or vise versa.
 ==Implementation Options==

@@ Line 3: / Line 3: @@
 At the past several project weeks and in developer discussions we have revisited the questions about which python packages should be included in Slicer core.
-Building Slicer with anaconda / miniconda has been evaluated but certain practical issues remain about relying on external binaries and resolving version issues (e.g. the conda-provided VTK could not be used with the Slicer provided VTK).
+[[{{FULLPAGENAME}}/PythonCondaBuild|Building Slicer with anaconda / miniconda]] has been evaluated but certain practical issues remain about relying on external binaries and resolving version issues (e.g. the conda-provided VTK could not be used with the Slicer provided VTK).
 Rather than dive deep into porting python build systems and supporting them inside Slicer maybe there's a better way...?
@@ Line 9: / Line 9: @@
 ==Concept==
-The SlicerBridge concept builds on the success with the MATLABBridge extension already existing in Slicer.  The idea is to treat anaconda in the same way we treat MATLAB, as an external process with a well defined interface for passing data and invoking remote computation.
+The SlicerBridge concept builds on the success with the [[Documentation/Nightly/Extensions/MatlabBridge | MATLABBridge extension]] already existing in Slicer.  The idea is to treat anaconda in the same way we treat MATLAB, as an external process with a well defined interface for passing data and invoking remote computation.
-In practice this could be as simple as a module launching the anaconda-based process and then connecting to it via OpenIGTLink.
+In practice this could be as simple as a module launching the anaconda-based process and then connecting to it via [http://openigtlink.org/ OpenIGTLink.]
 Benefits of this approach: