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
I think we have can get better in separating encointer stuff from the rest of the code. The current state is that whenever needed, we just added an encointer module there. However, I think the better approach would be to have the encointer stuff all in one place, and in crates instead of in submodules, which can then be imported in the app-libs crates. In some cases, this is absolutely straightforward, for other cases, we need some better separation of code, so the encointer crate do imports without introducing dependency cycles.
api-client-extensions // <- should be straighforward
cli/ // <- here we first need to extract some utils from the current cli code, so we don't get dependency cycles. Todo: define issue
commands
trusted-commands
The scheduler STF interface needs some more thinking, in how we can cleanly solve this without having to touch the executor, but it should be doable too. We need to think more generically here so that we can implement in app-libs an: on_update_state function, that the executor will call agnostic to the actual business logic.
The text was updated successfully, but these errors were encountered:
clangenb
changed the title
Improve separation from encointer-stuff
Improve separation of encointer-stuff
Jan 24, 2023
I think we have can get better in separating encointer stuff from the rest of the code. The current state is that whenever needed, we just added an encointer module there. However, I think the better approach would be to have the encointer stuff all in one place, and in crates instead of in submodules, which can then be imported in the app-libs crates. In some cases, this is absolutely straightforward, for other cases, we need some better separation of code, so the encointer crate do imports without introducing dependency cycles.
Target structure with the current code I see:
The scheduler STF interface needs some more thinking, in how we can cleanly solve this without having to touch the executor, but it should be doable too. We need to think more generically here so that we can implement in
app-libs
an:on_update_state
function, that the executor will call agnostic to the actual business logic.The text was updated successfully, but these errors were encountered: