First version of new API for Launch Manager - #377
Conversation
License Check Results🚀 The license check job ran with the Bazel command: bazel run --lockfile_mode=error //:license-checkStatus: Click to expand output |
|
The created documentation from the pull request is available at: docu-html |
|
It looks like it could work. To see if this if this is the right fit in combination with |
|
|
||
| /// @brief Activation happened automatically as part of a recovery action, | ||
| /// without an explicit State Manager request. | ||
| kRecoveryAction = 1 |
There was a problem hiding this comment.
I think we should add reason
There was a problem hiding this comment.
I assume this will mean we need to adapt ActivationCallback then.
https://github.com/eclipse-score/lifecycle/pull/377/changes#diff-0112cf4be18e494bec2720f425278091273c52be4ffbe12f527cd85178077895R66-R67
Do you have something in mind?
I like this suggestion. Would it be possible to add a dummy details/lm_controlimpl.hpp with a test that just shows how the API interaction would look like from the users perspective? |
| /// @error kRunTargetDoesntExist Name of the requested Run Target does not exist in current configuration. | ||
| /// @error kCommunicationError Connection with Launch Manager cannot be established and request cannot be | ||
| /// sent. | ||
| virtual score::Result<void> activate_run_target(std::string_view runTargetName, bool force = false) = 0; |
There was a problem hiding this comment.
should this not be RunTargetName
There was a problem hiding this comment.
@NicolasFussberger do you remember why we went with std::string_view here?
I have feeling that RunTargetName maybe better here... As this is what probably will travel through mw::com
There was a problem hiding this comment.
For consistency, RunTargetName is probably better.
Depending on how the data is represented in the mw::com interface it may then require an additional copy though.
| /// @error kCallbackInProgress A new callback cannot be registered because the | ||
| /// current callback is still executing. Retry after it returns. | ||
| /// @error kInvalidArguments The callback is empty. | ||
| virtual score::Result<void> register_run_target_activation_callback(ActivationCallback callback) = 0; |
There was a problem hiding this comment.
AFAIK within the context of the callback, you may not call other mw::methods / send events.
If this is true, it is not easily supported to trigger the next run target activation after the previous one finished (in the scope of the callback). User would need to store the information provided by the callback and then pick this up from a different thread.
@eduard-moskalchuk do you have some insights if this is true?
First draft of new API for Launch Manager