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

Feature/openrpc #3

Merged
merged 18 commits into from Mar 12, 2019
Merged

Feature/openrpc #3

merged 18 commits into from Mar 12, 2019

Conversation

@shanejonas
Copy link
Member

@shanejonas shanejonas commented Feb 27, 2019

resolves #4

I've made this proposal pretty generic.

The reasons for this are:

  • forces us to talk generally about the problems and advantages
  • to be able to make proposals to other projects easily
ECLIPs/ECLIP-2.md Outdated Show resolved Hide resolved
@shanejonas shanejonas requested a review from sorpaas Feb 27, 2019
ECLIPs/ECLIP-2.md Outdated Show resolved Hide resolved
ECLIPs/ECLIP-2.md Outdated Show resolved Hide resolved
ECLIPs/ECLIP-2.md Outdated Show resolved Hide resolved
ECLIPs/ECLIP-2.md Outdated Show resolved Hide resolved
@BelfordZ
Copy link
Member

@BelfordZ BelfordZ commented Feb 27, 2019

giphy 2

ECLIPs/ECLIP-2.md Outdated Show resolved Hide resolved
ECLIPs/ECLIP-2.md Outdated Show resolved Hide resolved
@meowsbits
Copy link
Member

@meowsbits meowsbits commented Feb 27, 2019

This seems simple and strong.

I'm now wondering if it might be still a little broad. idk, thinking on it.

in the meantime, I would suggest to add a little background on existing common API points or patterns (like Web3, eth_) to give some context to what a proposal to "add an(other) endpoint to all the APIs" kind of means.

ECLIPs/ECLIP-2.md Outdated Show resolved Hide resolved
ECLIPs/ECLIP-2.md Outdated Show resolved Hide resolved
# Add OpenRPC Service Discovery

ECLIP: 2
Title: Add OpenRPC Service Discovery
Copy link
Contributor

@zmitton zmitton Feb 27, 2019

Choose a reason for hiding this comment

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

...to multi-geth specifically? or to multigeth/geth/parity

Copy link
Member Author

@shanejonas shanejonas Feb 27, 2019

Choose a reason for hiding this comment

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

trying to keep it pretty generic so it could be proposed anywhere, even as say a BIP

Copy link
Contributor

@whilei whilei Feb 27, 2019

Choose a reason for hiding this comment

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

or for anything that has a JSONRPC server, eh?

Copy link
Member Author

@shanejonas shanejonas Feb 28, 2019

Choose a reason for hiding this comment

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

yea exactly

@phyro
Copy link
Contributor

@phyro phyro commented Feb 27, 2019

Blockchains probably share a lot of common functionality e.g. getBlock(height), getTransaction(txHash) etc. It is possible to do the openrpc.json thing for each one separately and that's already a huge win, but if they all agree on the same Blockchain functions spec, it would make it easier to for example build a generalized chain explorer (actually just a part of it because you'd need to fill the gas thing). This could be shooting in the dark, but perhaps it could also make it simpler to add coins to the exchanges if they follow the same interface description? If this makes sense, then in this case ETC openrpc.json would extend the blockchain openrpc document which could be described in the metadata.
I'm not even sure this is related to this ECLIP, but it might make sense just to put 10 minutes into thinking about this if it's something there. It could be done afterwards as some kind of a proxy rpc mapping to the actual implementation though, but that's more messy.

@BelfordZ
Copy link
Member

@BelfordZ BelfordZ commented Feb 27, 2019

@phyro should work that into a suggestion on this ECLIP

meowsbits and others added 3 commits Feb 27, 2019
Co-Authored-By: shanejonas <jonas.shane@gmail.com>
Co-Authored-By: shanejonas <jonas.shane@gmail.com>
Co-Authored-By: shanejonas <jonas.shane@gmail.com>
@r8d8
Copy link

@r8d8 r8d8 commented Feb 28, 2019

This seems simple and strong.

I'm now wondering if it might be still a little broad. idk, thinking on it.

in the meantime, I would suggest to add a little background on existing common API points or patterns (like Web3, eth_) to give some context to what a proposal to "add an(other) endpoint to all the APIs" kind of means.

I thought OpenRPC made to be single tool for API creation, and aiming to remove all custom specs, docs, etc. for API in clients, or?

BelfordZ added a commit to etclabscore/ethereum.go-ethereum that referenced this issue Mar 1, 2019
@meowsbits
Copy link
Member

@meowsbits meowsbits commented Mar 1, 2019

I just mean like a little more context in the document.

Like Add OpenRPC Service Discovery -> Add OpenRPC Service Discovery To JSONRPC Clients.

This is a proposal to add OpenRPC support by adding the method rpc.discover to the projects JSON-RPC API to enable automation and tooling.

-> This is a proposal to add OpenRPC support to existing and future Ethereum-familly RPC services by adding the method rpc.discover to these projects's JSON-RPC APIs, enabling automation and tooling.

edit suggestions suggested

ECLIPs/ECLIP-2.md Outdated Show resolved Hide resolved
ECLIPs/ECLIP-2.md Outdated Show resolved Hide resolved
BelfordZ referenced this issue in BelfordZ/starIPs Mar 2, 2019
fix: typo in CONTRIBUTING.md and compose command in BUILDING.md
BelfordZ referenced this issue in BelfordZ/starIPs Mar 2, 2019
fix: add video guide for making small documentation changes
- Mock Server generated in many languages
- Tests generated in many languages
- Documentation Generation

Copy link
Contributor

@phyro phyro Mar 3, 2019

Choose a reason for hiding this comment

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

Suggested change
### Possible benefits of standardized blockchain methods
Since Blockchains share a lot of common functionality, it would make sense for them to expose the same set of RPC methods that are common to all blockchains e.g. `getBlock(height)` or `getTransaction(txHash)`. The reuse of such blockchain methods could make certain tasks easier for services that need to integrate with multiple blockchains. Examples of services that could benefit from this include, but are not limited to:
- blockchain explorer for multiple chains
- exchanges listing new coins

Copy link
Member Author

@shanejonas shanejonas Mar 12, 2019

Choose a reason for hiding this comment

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

I think this is awesome. but maybe is another Improvement Proposal around BTC/ETC and other chains coming together on a good naming scheme for methods for these APIs?

Or I have other ideas around doing a meta-API t hat would allow this but its out of the scope of this ECLIP.

Copy link
Contributor

@phyro phyro Mar 12, 2019

Choose a reason for hiding this comment

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

@shanejonas agree, this seems more like something on top of this proposal

ECLIPs/ECLIP-2.md Outdated Show resolved Hide resolved
Copy link
Contributor

@stevanlohja stevanlohja left a comment

LGTM

@stevanlohja stevanlohja merged commit 7688e69 into etclabscore:master Mar 12, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

8 participants