What's everyone working on this week (5/2017)?


#1

New week, new Rust! What are you folks up to?


#2

I opened PRs to update a few libraries to serde 0.9. Having a dedicated Map type in serde_json now is great. It saves a lot of .as_object().unwrap() shenanigans. I’m working on some more fleshed out examples for elastic.

I’ve also started working on a tool to package Rust libraries as .NET nuget packages, because I didn’t feel like writing a 5 line shell script to copy DLLs around.


#3

Working on better support for deserializing untagged enums and internally tagged enums in Serde. These can be annoying to work with in previous versions.

#[derive(Deserialize)]
enum E {
    A { x: u8, y: u8 },
    B { z: u8 },
}

// existing representation in JSON
{ "A": { "x": 0, "y": 0 } }

// untagged enum representation
{ "x": 0, "y": 0 }

// internally tagged enum representation
{ "type": "A", "x": 0, "y": 0 }

#4

Work on my Cassandra driver written in Rust is still in progress. The goal for this week is to complete a coverage of v4 protocol. There’s only one gap here. It’s Register and Event frames which implementation will allow to subscribe to Cassandra server events.

Since my last update following stuff was implemented:

  • SSL-encrypted connection
  • prepare + execute query
  • batch queries

#5

Continuing on with STRATIS (https://github.com/viperscape/stratis), I started implementing postgres (using a great library https://github.com/sfackler/rust-postgres) as a persistent backend for the game. Now players can connect, chat; and when a player is offline, the chat that they would receive is saved to the database-- it gets sent to them when they reconnect. I made the backend agnostic using traits, because I don’t know if I will stick with postgres, dynamodb or even redis with journaling seem like good choices.

I’ve been implementing my own protocol because I’m not sure what the UI will end up as-- I might even use a game-engine like UE4 so making the protocol basic and easy to work with is important. Currently the protocol works as follows: first byte describes the action (login, chat, etc.) with subsequent bytes related to it; so in terms of chat the following two bytes describe the length of the chat string, which is then parsed easily from the stream. I think I’m going to try and make these as some sort of enum that handles parsing the header of each type of communication.