-
Notifications
You must be signed in to change notification settings - Fork 217
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Review Network Layer #60
Review Network Layer #60
Conversation
There was a bit of confusion IMO about where the network layer sits (understandable because there's no clear layout of what the architecture should / could be anywhere ...). Also, I took the opportunity to remove the 'Rust' part of the module names since this is quite irrelevant. We are programming to an interface (a.k.a the http-bridge API, and the implementation of that interface shouldn't really matter). Doing so, I've remove the unnecessary abstraction of the chain producer Monad. We won't be instantiating multiple network layer at once, so for now, this adds an extra layer of complexity that isn't needed. In practice we can just fallback to a plain data type that we instantiate using one service (e.g. the cardano-http-bridge) or another (e.g. the Haskell shelley node).
|
||
|
||
spec :: Spec | ||
spec = return () |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This allow for the code coverage to take this untested module into account.
( Spec ) | ||
|
||
spec :: Spec | ||
spec = return () |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This allow for the code coverage to take this untested module into account.
After this, I'd like to get the Also, I believe the implementation of the |
Issue Number
Overview
I have moved modules around and renamed them a bit (mostly to remove the 'Rust' part) and prepare the foundation to reflect on the upcoming architecture
I have removed the API newtypes
BlockHeader
andBlock
in favor of a newtypeApiT
which wraps existing primitive types from the wallet. This has the same effect, but doesn't yield to conflicting names (which messes up with various tooling liketags
and forces us to have qualified imports to disambiguate types from the API and types from the primitives).I have merged
MockNetworkLayer
with theRustHttpBridgeSpec
, and theRustHttpBridgeClient
withRustHttpBridge
. Generally speaking, I'd like to avoid us to spread too much with modules, it makes code hard to find in the long run and eventually end up with us duplicating functionality and logic in various places. If there's no good reason to have multiple modules, I'd rather stick as much as we can inside one.I have remove the ChainProducer monad in favor of an explicit type. Cf the comment below
I have moved some slotting comparison functions into the wallet primitives
Comments
There was a bit of confusion IMO about where the network layer sits (understandable because there's no clear layout of what the architecture should / could be anywhere ...).
Also, I took the opportunity to remove the 'Rust' part of the module names since this is quite irrelevant. We are programming to an interface (a.k.a the http-bridge API, and the implementation of that interface shouldn't really matter).
Doing so, I've remove the unnecessary abstraction of the chain producer Monad. We won't be instantiating multiple network layer at once and there's no meed for an abstraction ober this (really, we want to have different implementations behind a network layer but a plain concrete parameterised type is simpler and just fine)..The typeclass adds an extra layer of indirection and complexity that isn't needed.