Editing TheFramework (section)

==Message Format==
* Maybe just use Rust structs? Can redefine them separately later...
* Could use codegen... Can go from Rust structs to external format or visa-versa.
* Could keep them in Rust native and provide a C library interface to interact with them.

===Capnproto?===
* A bit of a pain to integrate into Rust.
* Plays well with other languages.
* Need to find out how to extent the codegenerated types with my own.
* Would need to use capnproto's internal native formats instead of Rusts.
* Good versioning...

===JSON?===
* I don't like JSON.
* It's fairly well known and supported.

===Enums vs "strings"?===
* Strings much more waste on the wire. Higher parsing overhead.
* Strings allow for custom types. Could just add a custom type enum that has a string.
* Enums could be 'backwards compatible' if you just ignore anything you don't understand.
* Strings wouldn't have to be predefined. But they would have to be used so defining them would be best anyway.

===Categorise messages by type, or one global type for all messages?===
* Categories could make it easier to ignore messages that have nothing to do with the service.
* One global type would be much easier to implement.
* Categories might be eaiser for reading documentation. But might be harder too as they might end up spread around.
* Maybe one global type with 'soft categories', ie categorise them based on the name but have one giant enum.