Some frameworks and libraries need to be explicitly initialized and shutdown.
For instance, ROS 2 application typically have several phases as described in the documentation of [rclpy](https://github.com/ros2/rclpy), ROS Client for Python¹:
A typical ROS program consists of the following operations:
Initialization
Create one or more ROS nodes
Process node callbacks
Shutdown
It might also be the case for other workflow which needs explicit setup and teardown of resources (e.g. access to files, connection to database, authentication to a service, etc.)
Problem
Currently, the setup and teardown of the framework has to be defined into a Flojoy Block.
This creates two issues:
Firstly, defining (potentially repeatedly) the setup and the teardown of frameworks used by Block, opacifies their logic and creates maitainance cost of supplementary (duplicated) logic.
Secondly, it might cause inefficiency or even failure during the execution.
For instance, if Blocks using ROS were to define ROS client lifetime via [rclpy.init](https://docs.ros2.org/foxy/api/rclpy/api/init_shutdown.html#rclpy.init), [rclpy.shutdown](https://docs.ros2.org/foxy/api/rclpy/api/init_shutdown.html#rclpy.shutdown) or even [rclpy.spin{,\_once,\_until_future_complete}](https://docs.ros2.org/foxy/api/rclpy/api/init_shutdown.html#rclpy.spin) and were to be used in the same application, this might create alternations of connections and disconnections. This would definitely come with slowness or inefficiencies or even failures due to the [rclpy.Context](https://github.com/ros2/rclpy/blob/b4b4702ecffd923548eadac6d35f3d90d2eb6f91/rclpy/rclpy/context.py#L59-L90)'s client inconsistent state since it is a Singleton.
Proposed Solution
Get some inspiration from Python context-manager but for Flojoy:
have the user specify a context (or specify it for them) conditionally to the use of some framework to perform the setup when the application enters the context (in the spirit of __enter__) and when it exit it (in the spirit of __exit__)
encapsulate several blocks' logic (or the application's) within a (global) context which the application will enter when it starts and exist when it stops.
The user must not know that such a context exist, but we must have a way to know that they need one so that we can setup the required logic.
Design plan:
identify frameworks and libraries which need specific initialization and teardown (for instance ROS 2)
design an abstract Context which would be subclassed for each framework
introduce a decorator for each framework requiring a context
decorate relevant Blocks accordingly
for a Flojoy application:
before starting the application, register the framework's Context if at least one Block decorator for the framework is used
Context
Some frameworks and libraries need to be explicitly initialized and shutdown.
For instance, ROS 2 application typically have several phases as described in the documentation of
[rclpy](https://github.com/ros2/rclpy)
, ROS Client for Python¹:It might also be the case for other workflow which needs explicit setup and teardown of resources (e.g. access to files, connection to database, authentication to a service, etc.)
Problem
Currently, the setup and teardown of the framework has to be defined into a Flojoy Block.
This creates two issues:
[rclpy.init](https://docs.ros2.org/foxy/api/rclpy/api/init_shutdown.html#rclpy.init)
,[rclpy.shutdown](https://docs.ros2.org/foxy/api/rclpy/api/init_shutdown.html#rclpy.shutdown)
or even[rclpy.spin{,\_once,\_until_future_complete}](https://docs.ros2.org/foxy/api/rclpy/api/init_shutdown.html#rclpy.spin)
and were to be used in the same application, this might create alternations of connections and disconnections. This would definitely come with slowness or inefficiencies or even failures due to the[rclpy.Context](https://github.com/ros2/rclpy/blob/b4b4702ecffd923548eadac6d35f3d90d2eb6f91/rclpy/rclpy/context.py#L59-L90)
's client inconsistent state since it is a Singleton.Proposed Solution
Get some inspiration from Python context-manager but for Flojoy:
__enter__
) and when it exit it (in the spirit of__exit__
)The user must not know that such a context exist, but we must have a way to know that they need one so that we can setup the required logic.
Design plan:
Context
which would be subclassed for each frameworkContext
if at least one Block decorator for the framework is usedReferences
1: https://docs.ros2.org/foxy/api/rclpy/api/init_shutdown.html
From SyncLinear.com | BLO-91