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

remove Val API and add links to outside spec/standards repos #1366

Merged
merged 2 commits into from
Aug 26, 2019

Conversation

djrtwo
Copy link
Contributor

@djrtwo djrtwo commented Aug 16, 2019

  • removed Validator API from specs repo. This API has been migrated to https://github.com/ethereum/eth2.0-apis and will serve as a central location for additional APIs as created and standardized.
  • add links for api, metrics, and interop standards repos to README

@djrtwo djrtwo requested review from hwwhww and protolambda August 16, 2019 19:38
README.md Outdated
@@ -37,6 +37,14 @@ See the [Eth 2.0 Phase 2 Wiki](https://hackmd.io/UzysWse1Th240HELswKqVA?view) fo
* [Beacon node API for validator](specs/validator/0_beacon-node-validator-api.md)


## Additional specifications for client implementers

Additional specifications and standards outside of core consensus can be found in the following repos:
Copy link
Contributor

Choose a reason for hiding this comment

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

Hmm, networking spec is also "outside of core consensus" but we leave them here for more visibility/engagements, right? Could you elaborate why only moving restful APIs away? Is it for letting the clients take eth2.0-apis
as a submodule?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

When I said outside of core consensus, I meant more broadly, that a client doesn't really have to implement any of these APIs. This only aids in interoperability and standards for dev tooling. The cycle on which these might emerge and the standards around them is likely to be pretty independent of the core specs. I also think we might want to write tests against these APIs which would even more so clutter this repo.

I mispoke with "core consensus". I meant more broadly, the things that a client must conform to.

@JustinDrake
Copy link
Contributor

What will happen to non-API standards (light client, test formats, networking, key store, HD wallets, checksums, ...)? Would it make sense to migrate standards to ethereum/eth2.0-standards (as opposed to eth2.0-apis which may be too "narrow")?

@protolambda
Copy link
Contributor

protolambda commented Aug 20, 2019

Generally I like tests, generation and formats to live together. But this doesn't mean we can't split it up. I would keep spec-tests, spec-tests-format, spec-test-generation, and welll... the spec, in this specs repository. But then move apis, apis-test-format, apis-test-generation etc. to the new apis repository. Same thing for the other eth2 components.

@djrtwo
Copy link
Contributor Author

djrtwo commented Aug 20, 2019

Right now some standards are being placed here and some in eth2.0-pm. Maybe makes sense for a new repo.

As for the light client, it is connected enough to the core spec that testing might be easier at lesat initially done here, but it too might evolve to an independent repo at some point

@djrtwo djrtwo merged commit 2abb81d into dev Aug 26, 2019
@djrtwo djrtwo deleted the remove-val-api branch August 26, 2019 14:42
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.

4 participants