You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As a BlockNode Developer (might be a third-party)
I want a decoupled extensible system that allows for async communications between modules and enables SPI
For that we need to create a communication system architecture based on events and pubSub messages channel.
This allows for asynchronous tasks and threads, as well as a completely decoupled system where any plugin can subscribe listen to the message types that it cares about.
Solution
Defining the Messages Types and fields as well as mechanism should take into consideration the different types of modules that we could have, the cardinality of each of those types that is allowed.
The purpose of the ticket is for design the solution and layout the path forward to implement it, should consider SPI capabilities and expected outcome is a MD document with a brief explanation of the protocol and a series of tickets that would be needed to complete the feature.
Alternatives
Keep using Singletons that are injected when created by Dagger, this is the current approach and although it works, and could continue to work, is not extensible friendly.
The text was updated successfully, but these errors were encountered:
Problem
As a BlockNode Developer (might be a third-party)
I want a decoupled extensible system that allows for async communications between modules and enables SPI
For that we need to create a communication system architecture based on events and pubSub messages channel.
This allows for asynchronous tasks and threads, as well as a completely decoupled system where any plugin can subscribe listen to the message types that it cares about.
Solution
Defining the Messages Types and fields as well as mechanism should take into consideration the different types of modules that we could have, the cardinality of each of those types that is allowed.
The purpose of the ticket is for design the solution and layout the path forward to implement it, should consider SPI capabilities and expected outcome is a MD document with a brief explanation of the protocol and a series of tickets that would be needed to complete the feature.
Alternatives
Keep using Singletons that are injected when created by Dagger, this is the current approach and although it works, and could continue to work, is not extensible friendly.
The text was updated successfully, but these errors were encountered: