Minimal separate process downloading blocks from Byron node #347
Conversation
paweljakubas
force-pushed
the
paweljakubas/330/adding-lean-decoupled-block-listener
branch
from
83407a2 to
e464dc1
Compare
[330] requestTip functionality working [330] Adding Block msg and using IORef [330] Adding working getBlock capability [330] cleaning and adding better abstractions - almost there [330] Enhancing operation, adding security parameter and README.md [330] stack2nix [330] hlint
paweljakubas
force-pushed
the
paweljakubas/330/adding-lean-decoupled-block-listener
branch
from
e464dc1 to
15d2d0c
Compare
| , cardano-sl-core | ||
| , cardano-sl-infra | ||
| , cardano-sl-networking | ||
| , cardano-sl-util |
There was a problem hiding this comment.
I am having a look at the PR now and will push some refactorings changes on the branch.
Note that, you've been cheating my friend 😛
The requirements said:
* The prototype _must_ not re-use code from an existing implementation (neither `cardano-sl`, nor `cardano-wallet`)
And... I see quite a lot of cardano-sl-*** dependencies here 🙃 ...
There was a problem hiding this comment.
yes, I used cardano-sl-networking node and converse primitives. They use quite sophisticated way of communication there...Other dependencies are just infra (BiP, bipPacking, PeerData, VerInfo - required to talk with the node), of course chain (Block, BlockHeader, etc for definitions), core (for NewestFirst) .
So I faced cardano-dependences vs simplicity trade-off. For me not using the abovementioned would mean very complicated, not easy to understand and error-prone code. cardano-sl-networking use not so easy, I would say cryptic, bidirectional communication protocol...
Nevertheless, I agree - in this version there are still dependencies. But it is simple on the other way
#330
Overview
Comments