API: Node info

[spikeekips]

The basic node information will be produced,

• node alias
• node status API: Node status to event stream #10 Create node status: 'consensus', 'catchup' and 'booting' #11
• public address
• endpoint
• validators
• connected validators(?)
• etc.

[anarcher]

What kind of node status is exist in node? IMHO, the node may have several statuses like below:

• Starting
• Catchup
• Synced
• Terminating

But I am not entriely sure that the statues are good naming or meaning to represent of node status.
What do you think about it?

ps) state can be better naming than status.. And status can display additional information (message log style?)

[spikeekips]

@anarcher What kind of node status is exist in node? IMHO, the node may have several statuses like below:

• Starting
• Catchup
• Synced
• Terminating

Several names are almost same I proposed at #11

• booting == Starting
• catchup == catchup
• consensus == synced

synced is the Stellar's term, so instead of that I want to use our own expression, booting. terminating is I missed, it can show that node is terminating with any reason.

But I am not entriely sure that the statues are good naming or meaning to represent of node status.
What do you think about it?

ps) state can be better naming than status.. And status can display additional information (message log style?)

'state' also has same meaning with 'status', but state is already used for ballot state like BallotStateINIT, BallotStateSIGN, so I think 'status' is good term. :) If you have another alternatives of 'status', let us know.

[anarcher]

I agree consensus is better than synced. :-) also, status make sense :-)
I missed #10
Thanks :-)

[leejames00]

Is Consensus intended for the nodes that have all (up to date) blockchain data ?
In that case, I think synced is better.

[outsideris]

How about consensus to consented or consenting.
consensus is nouns, so it is confused about what it represents for.

[leejames00]

I agree on not using consensus, but I can't think of a term to replace it

[spikeekips]

@outsideris @leejames00 I mean that consensus is the node can participate consensus process.

[kfangw]

several weeks ago I had been worked for this issue with PR #143
Do you think that this issue needed to be resumed? or any other opinion?
@anarcher

[kfangw]

several weeks ago I had been worked for this issue with PR #143
Do you think that this issue needed to be resumed? or any other opinion?
@anarcher

@anarcher ping

[anarcher]

IMHO, we consider to separate node info and client info. What do you think? :)

[kfangw]

OK I agreed. What information provided by the client node API you think?

[anarcher]

What do you think about it? :->

type Info struct {
    NodeVersion string `json:node_version`  // version/version
    NodeState  string `json:node_state`  // node/localNode.state
    NodeAlias  string `json:node_alias` // node/localNode.Alias
    BlockHeight uint64 `json:block_height`  // block/Block
}

[kfangw]

@anarcher thx ~ I will make a node API for a client based on what you suggested