Yeastplume - Progress update thread - Mar 19 to Sep 19

Update Friday, March 15th 2019

It’s St. Patricks weekend coming up, so don’t expect much coherence from me over the long weekend. Here’s what went on last week in the continuing saga of grin-wallet.

A couple of major pieces of work are underway. First, I’ve done quite a bit of work on slate version conversions to allow newer clients to communicate with older clients. This works by maintaining each slate version separately, and maintaining code that upgrades and downgrades versions, so if a slate v0 comes in and the wallet is on slate V2, it converts V0->V1->v2, operates on it, then (provided the incoming version is compatible,) converts back V2->V1->V0 to send it back. It’s quite a bit of code to maintain for each version and slightly inefficient, but at least it means that every new slate version just needs a single set of conversions (n-1 -> n, n -> n-1) to ensure backwards compatibility. That’s in place (but needs testing,) which means I can modify the v2 slate with impunity.

Second, I’ve turned my attentions to the V2 API. I have to give a shout out to Andrew Dirksen here, who’s put together an elegant and as-concise-as-possible system for generating the API, which also generates documentation that also acts as integration tests. To support this, he also put together a simplified json-rpc lib that I think is badly needed in the rust world. Now that I’ve had a chance to go over his work in detail, I’m very excited about this and think we’re going to have a very robust, consistent, flexible and self-documenting API v2 that should support all sorts of clients and suit everyone’s needs.

I’ve done some work towards completing the API, but in doing this I started to realize that in order to best take advantage of all of the good things Andrew’s approach to generating API v2 will bring, quite a bit of the code needs to be refactored. I’ll go over the exact changes I’m currently working on either in the issue or in a readme that explains the crate layout, but for now I’ll just say the current code that instantiates concrete wallet support structs and calls the api can definitely benefit from a better separation of concerns. Once this work is done, the code should be much cleaner, but also (very importantly) allow v2 api documentation tests that actually exercise the wallet code and act as complete integration tests as well.

So that’s where things are… naturally the code will need quite a bit of testing once this is done before 1.1.0 can be released, but the work is definitely worth it.

That’s it for now. Remember to enjoy Guinness responsibly.

6 Likes