Rewrite the I/O logic and define a protocol

[Snaipe]

This is mostly here to discuss and test anything related to the new protocol definition and the rewrite of the I/O logic.

The scope of this PR is to implement a client/server model, to start implementing the feature request #69.

The current technologies under test are:

• Protocol definition using the protobuf DSL.
• Protobuf implementation provided by nanopb.
• I/O abstraction provided by nanomsg.

nanopb should be more adequate than libprotobuf for serialization, as there seems to be a lot of effort done to make in run on embedded systems.

[Snaipe]

The current protocol definition can be found here

Breaking changes to this protocol will be possible until this rewrite hits a full release.

[codecov-io]

Current coverage is 90.01%

Merging #89 into bleeding will not affect coverage as of 4f43b0b

@@            bleeding     #89   diff @@
========================================
  Files             32      32       
  Stmts           1713    1713       
  Branches           0       0       
  Methods            0       0       
========================================
  Hit             1542    1542       
  Partial            0       0       
  Missed           171     171       

Review entire Coverage Diff as of 4f43b0b

Powered by Codecov. Updated on successful CI builds.

[ckaran]

Looks good! Although if you're going with protocol buffers, do you need the version field? Protocol buffers support a method of updating messages: https://developers.google.com/protocol-buffers/docs/proto3#updating. That said, I don't know what nanopb supports in terms of updated messages, so it may still be necessary.

[Snaipe]

The version field is mostly here to allow updated versions of the protocol that would be otherwise breaking backward compatibility -- although it might never be used at all, its just a safeguard. Message updating will still be used within a protocol version.

[ckaran]

OK, but isn't that the point of protocol buffers? So that you can detect if you have backwards-incompatible changes and deal with them in a sane manner? Or maybe I'm wrong... Eh, you're probably right, even if protocol buffers are able to deal with it, as human beings we like to see what version we're dealing with. I withdraw the comment! :-)

[Snaipe]

If you have backward-incompatible changes with protobuf, you're kinda screwed because the implementation deserialize the message as the new protocol regardless. This is why they tell you to never do that by never reusing field numbers (or making them reserved if you remove some), and not adding new required fields.

[Snaipe]

I'm going to merge this into bleeding -- the only bugs left come from the WIP on fork support for nanomsg and will be fixed in time. However, as there is a maintainer change undergoing over nanomsg and hence slower processing of PRs and reviews, and because the bleeding branch is slowly diverging from the changes introduced by the rewrite, it becomes necessary to merge the changes and iterate further on the new bleeding branch.

[am11]

👍

[ckaran]

I'm coming to the party late, but 👍 :)