-
Notifications
You must be signed in to change notification settings - Fork 87
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
Export static codecs #1894
Export static codecs #1894
Conversation
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.
I don't think this is the right approach, see my inline comments.
nodeDecodeQuery | ||
nodeEncodeResult | ||
nodeDecodeResult | ||
, pcLocalStateQueryCodec = staticLocalStateQueryCodec | ||
} | ||
|
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.
staticBlockFetchCodec
is missing. Ah, I see that's because it requires the TopLevelConfig
. This makes me think this is not such a good idea after all. Now you're just lucky that the codecs you need don't depend on the TopLevelConfig
and aren't versioned. What if they become versioned in the future? Or what if any of the node(Encode|Decode)X
methods suddenly start requiring the TopLevelConfig
? Then they can no longer remain "static".
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.
Yes, the idea is to replace the locally defined codecs in the Wallet
and cardano-rest and other places with these static-Versions of the codecs.
If in the future one of codecs becomes configurable,
the codec has to be removed from the exports.
This will break the libraries that uses this codec and the problem will be noticed.
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.
@mrBliss let's keep this part as simple as possible. The requirement here is to make it as easy as possible to run and maintain client applications (good example is cardano-cli get-tip
, it just needs to know the block type). Since node-to-client
protocols don't depend on TopLevelConfig
let's not include it. Do you see some dependency in forcible future? Will the LocalStateQuery
or LocalTxMonitor
protocols depend on parts of TopLevelConfig
? If so I think it's good to start with no dependency, and then add only the necessary dependencies. This will make us think how to properly do it when we will need it.
@MarcFontaine these codes should be versioned by NodeToClientVersion
. There's only one version now, but still it's better to put that already in place. I guess, they no longer become static.
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.
I guess it's fine for now. But as soon as they do start depending on the TopLevelConfig
, I don't want to be blocked by these static*
definitions.
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.
I actually want us to be blocked by them - this will give us moment to think how to make it as simple as possible for the clients as well.
staticBlockFetchCodecSerialised | ||
= codecBlockFetchSerialised | ||
(nodeEncodeHeaderHash (Proxy @blk)) | ||
(nodeDecodeHeaderHash (Proxy @blk)) |
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.
BTW, the style is:
staticBlockFetchCodecSerialised | |
= codecBlockFetchSerialised | |
(nodeEncodeHeaderHash (Proxy @blk)) | |
(nodeDecodeHeaderHash (Proxy @blk)) | |
staticBlockFetchCodecSerialised = | |
codecBlockFetchSerialised | |
(nodeEncodeHeaderHash (Proxy @blk)) | |
(nodeDecodeHeaderHash (Proxy @blk)) |
nodeDecodeQuery | ||
nodeEncodeResult | ||
nodeDecodeResult | ||
, pcLocalStateQueryCodec = staticLocalStateQueryCodec | ||
} | ||
|
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.
I guess it's fine for now. But as soon as they do start depending on the TopLevelConfig
, I don't want to be blocked by these static*
definitions.
@MarcFontaine I think it's worth putting all the client codecs in a recrod. Check this out how a client is instantiated: https://github.com/input-output-hk/cardano-node/blob/master/cardano-node/src/Cardano/CLI/Ops.hs#L406 it needs all the codecs, even if one of the mini-protocols is not sending anything. Could you go around various clients and check that we are right that there are clients that do not need
|
The wallet uses:
TopLevelConfig is not available in the wallet |
cardano-rest uses:
|
ok, good enough evindence for me we should avoid |
b343d99
to
9653e01
Compare
nodeToClientChainSyncCodec :: Codec (ChainSync (Serialised blk) (Tip blk)) | ||
failure m bytesLCS | ||
, nodeToClientTxSubmissionCodec :: Codec (LocalTxSubmission (GenTx blk) (ApplyTxErr blk)) | ||
failure m bytesLTX | ||
, nodeToClientStateQueryCodec :: Codec (LocalStateQuery blk (Query blk)) | ||
failure m bytesLSQ |
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.
Are these ::
aligned with those in ProtocolCodecs
? That's not necessary, just align these three with each other, like stylish-haskell
does.
, nodeToClientTxSubmissionCodec = staticLocalTxSubmissionCodec | ||
, nodeToClientStateQueryCodec = staticLocalStateQueryCodec | ||
} | ||
|
||
staticBlockFetchCodecSerialised |
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.
Please hide them in a where
clause, then you can rename them as nodeToClientCHainSyncCodec
, ... and take advantage of NamedFieldPuns
extension:
nodeToClientCodecs NodeToClientV_1 = NodeToClientCodecs {
nodeToClientChainSyncCodec
, nodeToClientTxSubmissionCodec
, nodeToClientStateQueryCodec
}
where
nodeToClientChainSyncCodec = ...
nodeToClientTxSubmissionCodec = ...
nodeToClientStateQueryCodec = ...
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.
At the moment the same codecs are exported via two different ways via ProtocolCodecs
and via NodeToClientCodecs
.
Maybe the nodeToClient codecs should be removed from ProtocolCodecs altogther ?
staticLocalChainSyncCodec
is the single definition that is uses for both exports.
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.
I see; you should have access to NodeToClientV_1
there too, no? Then you can unpack the record and add the codes. This way in the future one will only need to modify nodeToClientCodecs
to update codecs in consensus.
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.
OK! Done
6c64362
to
92fd70f
Compare
92fd70f
to
a9290cc
Compare
These codecs (currently) do not depend on ToplevelConfig.
a9290cc
to
9dcad93
Compare
bors r+ |
Export a record with all NodeToClient codecs,
These codecs (currently) do not depend on ToplevelConfig.
This PR makes these codecs usable in the wallet.