Step 0. Make it compile (and sort of run)

Long ago I was taught a dictum and I have yet to encounter a situation in software development to which it did not apply. I was taught that there are three steps to building fast, high quality services: “Make it run, make it right, make it fast.”

For my key value store I have not made it across the first threshold but this little project deserved its own 0th step which passes for the first time with this commit which required a bit of deviation from the blueprint in the README I referenced in the last post. Note the goalposts for this commit were that it compile and bind to a socket when invoked via cargo run. For now all parameters are hard coded, using clap to make them configurable with flags will be pretty simple and for now with everything hardcoded I can use cargo run with minimal friction.

The part I spent the longest figuring out was the input and output transport factories, not only did I need to change from Compact to Framed (I have no idea why the example uses Compact despite the public crate appearing to have no support for it) which also changes the names to read and write instead of input and output. I also added the mysterious constant 10 to the end of the constructor of the TServer (TSimpleServer in the example, again not sure why this isn’t in the public crate) which controls the thread pool size.

The KVServer struct is pure cargo cult in this commit, and it will be the focus of our next entry where we begin figuring out what is required to get a naive implementation which actually allows creating and manipulating keys. This is going to be fun I suspect since the handlers take immutable borrows of the server itself, so some form of interior mutability is going to be on the menu.

We will also have to fairly quickly take a detour into building a minimal client so we can start proving that this thing actually does what we say it does.