| Time | Item | Who | Notes |
|---|
| 10 min | Current status of the API | Chris Kirkwood-Watts | - What is in his plan
- Implemented
- Imagined
|
| Lykka requirement |
| - They want us to implement a small api. Get transaction, captured in the doc that Greg sent.
- it's a JSON ish thing.
- Lykka's document seems not very 'professional' - they may have a higher tolerance for dealing with the churn in JSON. Low expectations of quality.
|
| Meta mask requirements |
| - The MetaMask guys are wanting a specific API - Chris is feeling that the JSON RPC API is the most standard one out there.
- What ETH made difficult, getting the true state of the chain without running a node. They had to pull in all the headers and the chain outline. No light client. Wound up querying their own servers to obtain the state.
- Any complaints with versioning issues? Not according to Chris.
|
| 20 | How we get to a Protobuf implementation of the API | Everyone | - Write a nice protobuf API that everyone can use.
- Will have to have the largest surface area. Every bit of data you need has to be exposed.
- For each Key implementation, write a REST API in Python (no type safety possible - and it's fast).
- little HTTP servers that take the Protocol buffer output and pass it to a REST API.
- Concerns around level of effort - JSON is fast and easy.
-
- Or should we use Thrift? Nash is not opposed to this.
- DECISIONS
- Going forward, prioritize implementation of Protobuf solution, over JSON or other solutions other groups might want.
- Implement a GRPC Protobuf solution as the base Node API
- Nash approves including the work done to-date on the JSON RPC in the 15 March release
- Streaming data via Protobufs isn't perfect, and we may need to perform low level optimizations.
- How do we expose the storage log in an API for the 3/15 release?
|