Summary
An API to easily be able to integrate Topologiq into other systems has been requested. It would be worth checking if and how far are we into being able to offer one such thing.
Relevant ideas
Since Topologiq is a bit of a blackbox, it really only needs to expose one or at most a few functions.
All calls to the algorithm necessarily go via ./src/topologiq/runner.py : runner().
That said, it might be worth making wrapper functions that call the main runner in different manners. So, for instance, a straightforward wrapper would call the method on an entire circuit, but a different wrapper could take several circuits (subroutines/segments of a circuit) and call the runner for each separate subroutine. In time, an additional wrapper might be used to call a yet-to-be-implemented joiner.
This would allow separating API calls from the internal logic of topologiq, which should avoid or at the very least minimise the risk of breaking the API if/when things change significantly.
Linkages to other issues
The solution to this issue should consider the new structure proposed in #31.
Ideas welcome
This issue is purposely general to invite ideas for implementation by others.
Summary
An API to easily be able to integrate Topologiq into other systems has been requested. It would be worth checking if and how far are we into being able to offer one such thing.
Relevant ideas
Since Topologiq is a bit of a blackbox, it really only needs to expose one or at most a few functions.
All calls to the algorithm necessarily go via
./src/topologiq/runner.py:runner().That said, it might be worth making wrapper functions that call the main runner in different manners. So, for instance, a straightforward wrapper would call the method on an entire circuit, but a different wrapper could take several circuits (subroutines/segments of a circuit) and call the runner for each separate subroutine. In time, an additional wrapper might be used to call a yet-to-be-implemented joiner.
This would allow separating API calls from the internal logic of topologiq, which should avoid or at the very least minimise the risk of breaking the API if/when things change significantly.
Linkages to other issues
The solution to this issue should consider the new structure proposed in #31.
Ideas welcome
This issue is purposely general to invite ideas for implementation by others.