Difference between revisions of "Documentation/Labs/SlicerBridge"
From Slicer Wiki
(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....") |
|||
| (2 intermediate revisions by the same user not shown) | |||
| 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. | 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). | + | [[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...? | 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== | ==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: | 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 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 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. | * 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. | ||
| + | * The Slicer core doesn't grow to include major new dependencies. | ||
==Implementation Options== | ==Implementation Options== | ||
Latest revision as of 16:21, 26 January 2016
Home < Documentation < Labs < SlicerBridgeMotivation
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. 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.
- The Slicer core doesn't grow to include major new dependencies.
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?
