Skip to content
This repository has been archived by the owner on Sep 26, 2019. It is now read-only.

RLP encode subcommand #944

Conversation

NicolasMassart
Copy link
Contributor

@NicolasMassart NicolasMassart commented Feb 22, 2019

PR description

Add RLP encoding subcommand for at least ibftExtraData to be inserted in genesis file.

There's only one encodable type for the moment, however the --type option is already there with a default value on this type. We'll add the more possible types later if needed and the current type will remain the default one.

The file output is optional and it writes to standard output by default, same for
standard input or a file.

Tests and doc changes are added.

Fixed Issue(s)

fixes PAN-2318

…is file

This is intentionally not a generic command as anyway RPL encoding is specific
to each type of data.
It was coded with efficiency in mind and as there's only one encodable type for
the moment, the --type option is not provided. We'll add the option later if
needed and the current type will be the default one.
However a RLPEncodable interface is added to handle the RLP encode behaviour.
JSON annotations were added for type mapping.

made the file output optional and write to standard output by default, same for
standard input.

Some mnore tests are required, this is a preview version.
@NicolasMassart NicolasMassart added work in progress Work on this pull request is ongoing api Related to public APIs labels Feb 22, 2019
@NicolasMassart NicolasMassart self-assigned this Feb 22, 2019
@rain-on rain-on self-requested a review February 25, 2019 04:06
…with JSON @

Also found a way to make the enum able to return a type in a generic way using
an interface so the `--type` option can be used. We still have only one type
but at least it's ready for two.

Still some unit tests to add in the next commit.
moved the provider interface into the enum as only used by it for impl purpose
* Adapter to convert a typed JSON to an IbftExtraData object This adapter handles the JSON to RLP
* encoding
*/
public class IbftExtraDataCLIAdapter implements JSONToRLP {
Copy link
Contributor

Choose a reason for hiding this comment

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

Instead of an extra interface with an adapter, I think it would be more concise and direct to move the method body into the enum type and add an "encode" method on that enum:

shemnon@e178baf

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The thing is that for now we only have one type in the enum but we may end up with more and I wanted to keep the enum as simple as possible by just referencing an adapter and have one adapter for each data type, well isolated into each class file. But why not. What would you think @mbaxter and @rain-on ?

Copy link
Contributor

Choose a reason for hiding this comment

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

You can use the same brace-initialized-enum-value pattern for future encoders, so this doesn't preclude more values in the enum.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

No it doesn't but the more values we'll have in the enum the more code we'll have and I'm happier with small files when possible. But I admit your proposal removes a class and an interface so why not. Waiting for a second advice.

Copy link
Contributor

Choose a reason for hiding this comment

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

keeping the enum simple makes sense to me

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Indeed I would like to try to start splitting things to prevent mega classes like PantheonCommand. CLI is usually the place where you enter Pantheon so having it very easy to navigate seems important to me. So yes it requires a bit more classes and interfaces but it also makes it easier for someone new to understand and add a feature in my opinion.

Copy link
Contributor

@smatthewenglish smatthewenglish left a comment

Choose a reason for hiding this comment

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

LGTM

@NicolasMassart NicolasMassart removed the work in progress Work on this pull request is ongoing label Feb 25, 2019
@NicolasMassart NicolasMassart merged commit 9d2a67c into PegaSysEng:master Feb 25, 2019
ajsutton pushed a commit to ajsutton/pantheon that referenced this pull request Feb 26, 2019
Add RLP encoding subcommand for at least ibftExtraData to be inserted in genesis file.

There's only one encodable type for the moment, however the `--type` option is already there with a default value on this type. We'll add more possible types later if needed and the current type will remain the default one.

The file output is optional and it writes to standard output by default, same for
standard input or a file.

Tests and doc change.
NicolasMassart pushed a commit that referenced this pull request Feb 26, 2019
RLP encode subcommand backport (#944)

Add RLP encoding subcommand for at least ibftExtraData to be inserted in genesis file.

There's only one encodable type for the moment, however the `--type` option is already there with a default value on this type. We'll add more possible types later if needed and the current type will remain the default one.

The file output is optional and it writes to standard output by default, same for
standard input or a file.

Tests and doc change.
@NicolasMassart NicolasMassart deleted the feature/PAN-2318_rlp_encode_subcommand branch March 12, 2019 16:24
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
api Related to public APIs
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants