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

Research Spike: Design work on Data Access API #150

Closed
nathan-at-least opened this issue Nov 6, 2019 · 3 comments
Closed

Research Spike: Design work on Data Access API #150

nathan-at-least opened this issue Nov 6, 2019 · 3 comments

Comments

@nathan-at-least
Copy link

@nathan-at-least nathan-at-least commented Nov 6, 2019

No description provided.

@alchemydc

This comment has been minimized.

Copy link

@alchemydc alchemydc commented Jan 22, 2020

See #142

@alchemydc

This comment has been minimized.

Copy link

@alchemydc alchemydc commented Jan 27, 2020

Spike is likely able to be finished within a single sprint. Will require peering / meeting with Kevin as well as other engineers on Core.

@steven-ecc steven-ecc added this to the Core Sprint 2020-05 milestone Jan 30, 2020
@str4d str4d added the committed label Jan 30, 2020
@str4d

This comment has been minimized.

Copy link
Contributor

@str4d str4d commented Feb 12, 2020

I synthesised the various requirements from the issue and sketched out a draft design for the Rust components. I met with @gmale, @pacu, and Aditya today to discuss the issue, and a partial outcome was that they were happy with the draft design as the logic core. It would likely be wrapped in various different ways (e.g. directly via FFI, or inside a gRPC server) depending on the usage context, but for the most part the Rust core design seems extensible enough to handle this.

Next steps:

  • Identity what is necessary to store/retrieve at the data level.
  • Work out the initial Wallet API surface.
  • Figure out how to handle block data synchronization, and whether this should be synchronous or not.
    • Initially this will probably be two synchronous API calls, one that is per-block and another that is per-block-range, which make callbacks internally for status updates.
  • Map out the callbacks the clients care about (e.g. "block scanned", "balance changed", "transaction received")
  • Implement the above in an initial prototype.

I'll update the issue with a fuller sketch in the next sprint (which starts tomorrow).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants
You can’t perform that action at this time.