Improve message handler pluggability #17
Comments
This was referenced Sep 19, 2022
stoyan-zoubev
added a commit
to SoftwareDefinedVehicle/kanto-azure-connector
that referenced
this issue
Oct 12, 2022
- removed internal registries for telemetry and command handlers - launcher now expects to get handlers instead of using the internal registries - handlers.go moved from message/handlers/common to message/handlers, package changed to handlers, common directory deleted - packages command and telemetry merged into one package passthrough - message/handlers/command/passthrough_handler_*.go moved as message/handlers/passthrough/command_handler_*.go - message/handlers/telemetry/passthrough_handler_*.go moved as message/handlers/passthrough/telemetry_handler_*.go - "passthrough" strings inside the source files removed as it now matches the package name - removed unused stopRouter method from main.go Signed-off-by: Stoyan Zoubev <[email protected]>
e-grigorov
pushed a commit
that referenced
this issue
Oct 13, 2022
[#17] Improve message handler pluggability - removed internal registries for telemetry and command handlers - launcher now expects to get handlers instead of using the internal registries - handlers.go moved from message/handlers/common to message/handlers, package changed to handlers, common directory deleted - packages command and telemetry merged into one package passthrough - message/handlers/command/passthrough_handler_*.go moved as message/handlers/passthrough/command_handler_*.go - message/handlers/telemetry/passthrough_handler_*.go moved as message/handlers/passthrough/telemetry_handler_*.go - "passthrough" strings inside the source files removed as it now matches the package name - removed unused stopRouter method from main.go Signed-off-by: Stoyan Zoubev <[email protected]>
Repository owner
moved this from In Review
to Done
in Eclipse Kanto
Oct 13, 2022
stoyan-zoubev
added a commit
to SoftwareDefinedVehicle/kanto-azure-connector
that referenced
this issue
Oct 13, 2022
- Separate interfaces for c2d and d2c messages - CommandHandler and TelemetryHandler - Removed AzureSettings parameter from handler Init method, static parameters should be passed to handler constructors. - MessageHandler.Init method receives cloud connection info only (this is data that may not be known at the time of handler creation) - Device ID, Hostname, etc. - Simplified test methods Signed-off-by: Stoyan Zoubev <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Currently registries are used to store command and telemetry message handler instances. Message handler implementations are private and register themselves in the respective registries using golang
initfunctions. On the other side, the app launcher uses these registries while starting the azure connector.In order to allow easy extensions and customization by adding new handler implementations, the current scheme may be modified. A better approach is to:
mainmethod shall instantiate message handlers and pass these instances to the launcher'sMainLoop.Thus,
mainmethod has the full control over the message handlers. It can easily add new handlers or remove some of the handlers, e.g. don't use the default passthrough command handler if you do not want all the cloud messages to be forwarded locally.Additionally the common Azure settings (connection string, sas token validity, idscope, local broker settings, log settings, etc.) should be decoupled from handler-specific settings. So that when doing extensions/customizations, e.g. disabling/replacing passthrough command handler, its settings will not be needed at all. A separate issue will be posted to cover this topic.
The text was updated successfully, but these errors were encountered: