So before we jump into the last week’s overall update, thought I’d also give you guys a summary of
What's been done in terms of the overall code-base and RUST in particular as part of the test iteration and where we are currently with it.
So as you guys probably know, last week we saw the end of the Test iteration we took with RUST. It was a fun ride with a few bumps along the way having to play about with the different nightly builds and maintaining the code-base with constant updates from various third party dependencies we had (huge thanks to the RUST team for delivering the beta that simplified a lot of these issues and the rust community too for helping us along the way ). We managed to get a lot of the C++ code ported over as we mentioned in the previous update and the github todo’s were updated accordingly.
It’s worth noting that for 2 weeks of the 3 week duration we did not have the full team in the test iteration. We had Qi from the core team with the frontend team and were very much scoping the process. As you might have seen from the github repo activities, we had great progress which motivated us to get the entire team onto the test iteration for the last week. With quite a lot of the guys away on annual leave(yeh we wondered what those things are too ) we extended the test iteration for another week. This fourth week saw the CRUST library take shape and major parts of routing also catching up. At the end of the iteration we got the CRUST module to a point where it was based on TCP connections(UTP coming soon) to handle transport between nodes and the routing library with the basic implementation to connect the various Interfaces across vaults/client. Client self authentication parts were brought over and tested fine(not network wide yet). Libraries such as Self encryption hit the v0.1 mark where it had it’s example binaries also published and the crates for all the modules updated accordingly. So yeh an eventful few weeks
Last week, with the majority of the team finishing up any pending points from the test iteration / re-factoring code for best practises, we locked David, Fraser, Prakash, Nick and myself in the “room with a brilliant echo” (the guys that watched our google hangouts would know ) to plan the objectives for the first official RUST iteration (Take it from me, this is not a group of people you want to be stuck in a room with ). Our plan for the next iteration starting today was to focus on getting the Routing / CRUST libs to a much more stable state(handle Churn / Cache). This means the current iteration is still based on TCP for the transport layer, however worth considering that the CRUST API’s are now locked to cater for a dual protocol between TCP/UTP so adding UTP protocol should be a moderately simple task. With Routing’s Sentinel layer also handling merge functionality, simple vault binaries with installers should start emerging at the end of this iteration. Client binaries are also factored into the sprint however there isn’t going to be any storage API’s exposed as part of this iteration. Clients will allow creating/logging into an account using self authentication and maybe also storing / retrieving simple chunks by implementing a few interfaces directly from routing to showcase basic storage functions. This is a two week iteration and is currently underway.
Anyone tracking updates via Github might be missing all the activity in the RUST libs since they have been in David’s github id for the Test iteration. We’ve chosen to leave them there for this iteration. At the end of this current sprint, these will be migrated to the maidsafe organisation in github and a overall cleanup of existing repo’s under the maidsafe org will occur at the same time.
If you’re impatient to wait two weeks for this basic system in RUST, @dirvine has a few goodies(yay!!) for you today in the following update :
To solidify and distribute our core development in line with the improved processes and language we will now improve weekly updates by distributing value directly. This means code/tests/improvements/applications etc. we will attempt to provide a deliverable every fortnight at the most. To begin we are providing a very simple but useful library that we have released to the community. As you know all our code and development is open, so when we say release we really mean
focus on as far as these deliverables go.
message_filter here has a specific purpose (apart from what it does). This is a very small library and appears in crates.io - message_filter. This is a mechanism to allow very simple sharing of code. You will notice the version is a triple. We are working right now with the release part (middle) as a fast moving API. As the libs get to version 1.0.0 the API for version 1 will be stable and hopefully backwards compatible.
The main idea here is to introduce any potential contributors to the code base and as we progress (in defined iterations) we will provide simple examples that showcase the use-cases of the various libraries. This will build up to a full understanding of all the system components and allow many people to put their eyes on the code and help with quality, security and importantly maintainability. It also makes us feel better to be delivering quickly and regularly.
The front page of the libs in github will tell you what the library is and it’s current test status on various platforms. You will also see code coverage figures which will give an indication of how well tested it is (coverage is a poor measurement of tests, but the more the better, so it is useful, but not authoritative).
To contribute/use these libs you can try:
git clone firstname.lastname@example.org:dirvine/message_filter.git
cargo buildand it’s built with all dependencies etc.
cargo bench(this requires using the nightly version of rust for the next few weeks as they stabilise the bench module)
- Edit docs/code as needed
- run tests again to verify all is good
git commit -m"Edit to change X-Feature"
git pushto push to your repository
There ya go, just another week in the office @ MaidSafe This week’s overall catchup transcript