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

Add subtype field for state blocks in RPC block_info, blocks_info #1774

Merged
merged 5 commits into from Feb 25, 2019

Conversation

@SergiySW
Copy link
Collaborator

commented Feb 24, 2019

@SergiySW SergiySW added this to the V19.0 milestone Feb 24, 2019

@SergiySW SergiySW self-assigned this Feb 24, 2019

@SergiySW SergiySW requested review from wezrule and cryptocode Feb 24, 2019

@SergiySW SergiySW added this to CP0 in V19 Feb 24, 2019

Show resolved Hide resolved nano/node/rpc.cpp Outdated
Show resolved Hide resolved nano/node/rpc.cpp
@severalif

This comment has been minimized.

Copy link

commented Feb 24, 2019

I think it would be useful to include this information in the RPC callback as well.

@SergiySW

This comment has been minimized.

Copy link
Collaborator Author

commented Feb 25, 2019

@severalif callback is updated as well

@SergiySW SergiySW merged commit 0159417 into nanocurrency:master Feb 25, 2019

2 checks passed

continuous-integration/appveyor/pr AppVeyor build succeeded
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
@renesq

This comment has been minimized.

Copy link

commented Mar 15, 2019

Callback didn't have a subtype field, because a state block can have multiple purposes at the same time, so the "is_send" flag was introduced instead, which is less misleading but super helpful for programming an app. I don't think the "subtype" makes any sense here at all, because it will give you no further info that you could get by having the "is_send" flag and looking at the callback content ("amount"!). It will just add more traffic.

@SergiySW

This comment has been minimized.

Copy link
Collaborator Author

commented Mar 15, 2019

@renesq unfortunantely some services not willing to understand many things in Nano. The simpler, the better

@renesq

This comment has been minimized.

Copy link

commented Mar 15, 2019

In that case, revise the current block concept as a whole. Details in #1832

@SergiySW

This comment has been minimized.

Copy link
Collaborator Author

commented Mar 15, 2019

Yes, several heavy issues exists with state blocks design, but making new types again with a lot of legacy types support

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.