As promised, we are back into the normal Dev Update cycle and continuing on from the Update a few days ago. By popular demand we shall continue on with the same format of assigning team member names against the peer programmed tasks that we are currently focusing and working on.
##Crust - uTP / API : Vinicius / Peter / Andrew / Spandan / David
@ustulation , @canndrew , @Peter_Jankuliak and @dirvine are continuing peer programming the mini refactor in Crust; the objectives are to get a better understanding of current Crust functionality, clean up the code and tests along the way, but mainly to get on the same page in designing the new API. The current API, while feature complete, requires too much decision making to be done in the upper layers (read Routing) and it has been decided that Routing has its own set of responsibilities it has to deal with and that Crust should shoulder as much of the burden as possible from any user of the library. @vinipsmaker reckons uTP looks very solid and he is in the midst of testing and verifying this, so we are looking in good shape here now as well.
##Routing - Vault Integration : Andreas / Brian / David
The Routing documentation is currently being expanded to make it easier to understand and use, with enhanced explanations of the bootstrapping process, churn and handling the different data types; work continues in this area.
##Vaults : Adam / Fraser / Qi / David
Vaults were further pruned down and refactored to match the updates to Routing’s new API. There is still more to be done, but with @qi_ma back on board this isn’t anticipated to take too long.
As advised in the last update, Routing now has an example which closely matches the anticipated behaviour of Vaults. While this is useful on its own as an example (and test) of Routing usage, it’s also highly useful in implementing Vaults. If Vaults follow the paradigms set out in this example, it stands to reason that if this example works, Vaults should work. If Vaults stop working and we’re suspicious that Routing is to blame, we can examine the differences between Vaults’ use of Routing and this example to try and see if or why that hypothesis is correct.
With @Viv off for the next month, @dirvine and @anon86652309 have correspondingly increased workloads, but despite that, we’re hopeful that much of the work required in Vaults can be picked off by @qi_ma and @adam . This should let us have a testnet of Vaults up and running in the not too distant future.
##Client - Launcher : Krishna / Spandan / Shankar
A POC for the new launcher approach was demo’d last week. The approach has been detailed in this RFC.
We are expecting that this approach will make the lives of the end users and the developers much easier.
To make it simpler for app developers, the APIs are exposed through a local RESTFUl service instead of the IPC approach. The RFC also details the advantages of using a local HTTP proxy component along with the local server. Browsers will be able to serve requests, which end with the .safenet TLD through the proxy.
This week the two RFCs (Old vs New approaches) are to be discussed. Once one of the RFCs is accepted, implementation tasks will be planned and added to JIRA.
##Development roadmap : Scott
The initial design for the roadmap is now complete. Last week saw the design of the mobile interface mocked up and the UI will be slightly different to desktop. A menu on top and a descriptive view to drill down into. There is no graph style interface and in its place is the description of the feature and which tasks / features are dependencies and which ones are dependents. The graph was removed on mobile because of the obvious lack of space and the impact this would have on the user experience. The finished design for mobile is attached below and implementation is planned to begin at the end of this week.
So steady headway is being made on the tasks we outlined in the last Dev Update, the team’s heads are down and spirits up - a very good start to the year.
Link to the transcript
