Skip to content
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

Merged
merged 1 commit into from
Apr 7, 2020
Merged

Export static codecs #1894

merged 1 commit into from
Apr 7, 2020

Conversation

MarcFontaine
Copy link
Contributor

@MarcFontaine MarcFontaine commented Apr 2, 2020

Export a record with all NodeToClient codecs,
These codecs (currently) do not depend on ToplevelConfig.
This PR makes these codecs usable in the wallet.

Copy link
Contributor

@mrBliss mrBliss left a 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
}

Copy link
Contributor

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".

Copy link
Contributor Author

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.

Copy link
Contributor

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.

Copy link
Contributor

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.

Copy link
Contributor

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.

Comment on lines 281 to 284
staticBlockFetchCodecSerialised
= codecBlockFetchSerialised
(nodeEncodeHeaderHash (Proxy @blk))
(nodeDecodeHeaderHash (Proxy @blk))
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

BTW, the style is:

Suggested change
staticBlockFetchCodecSerialised
= codecBlockFetchSerialised
(nodeEncodeHeaderHash (Proxy @blk))
(nodeDecodeHeaderHash (Proxy @blk))
staticBlockFetchCodecSerialised =
codecBlockFetchSerialised
(nodeEncodeHeaderHash (Proxy @blk))
(nodeDecodeHeaderHash (Proxy @blk))

nodeDecodeQuery
nodeEncodeResult
nodeDecodeResult
, pcLocalStateQueryCodec = staticLocalStateQueryCodec
}

Copy link
Contributor

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.

@coot
Copy link
Contributor

coot commented Apr 6, 2020

@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 TopLevelConfig?

  • cardano-wallet
  • cardano-rest
  • clients in cardano-node

@MarcFontaine
Copy link
Contributor Author

The wallet uses:

codec :: Codec protocol DeserialiseFailure m ByteString
codec = codecChainSync
        encodeByronBlock
        (unwrapCBORinCBOR $ decodeByronBlock (toEpochSlots getEpochLength))
        (encodePoint encodeByronHeaderHash)
        (decodePoint decodeByronHeaderHash)
        (encodeTip encodeByronHeaderHash)
        (decodeTip decodeByronHeaderHash)

TopLevelConfig is not available in the wallet

@MarcFontaine
Copy link
Contributor Author

cardano-rest uses:

localTxSubmissionCodec
  :: forall m blk . (RunNode blk, MonadST m)
  => Codec (LocalTxSubmission (GenTx blk) (ApplyTxErr blk)) DeserialiseFailure m LBS.ByteString
localTxSubmissionCodec =
  codecLocalTxSubmission
    nodeEncodeGenTx
    nodeDecodeGenTx
    (nodeEncodeApplyTxError (Proxy @blk))
    (nodeDecodeApplyTxError (Proxy @blk))
```
But `TopLevelConfig` is available.

@coot
Copy link
Contributor

coot commented Apr 6, 2020

ok, good enough evindence for me we should avoid TopLevelConfig

Comment on lines 278 to 283
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
Copy link
Contributor

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
Copy link
Contributor

@coot coot Apr 6, 2020

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 = ...

Copy link
Contributor Author

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.

Copy link
Contributor

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK! Done

@MarcFontaine MarcFontaine force-pushed the mafo/static-codecs branch 2 times, most recently from 6c64362 to 92fd70f Compare April 7, 2020 10:40
These codecs (currently) do not depend on ToplevelConfig.
@MarcFontaine
Copy link
Contributor Author

bors r+

@iohk-bors
Copy link
Contributor

iohk-bors bot commented Apr 7, 2020

@iohk-bors iohk-bors bot merged commit d8cf08c into master Apr 7, 2020
@iohk-bors iohk-bors bot deleted the mafo/static-codecs branch April 7, 2020 12:14
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants