-
Notifications
You must be signed in to change notification settings - Fork 180
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rewrite the I/O logic and define a protocol #89
Conversation
The current protocol definition can be found here Breaking changes to this protocol will be possible until this rewrite hits a full release. |
Current coverage is
|
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. |
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. |
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! :-) |
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. |
2e07ebe
to
55187c7
Compare
15815e9
to
2d5ff78
Compare
2d5ff78
to
215e8dc
Compare
4253440
to
9421d5b
Compare
773b1f7
to
0019864
Compare
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. |
👍 |
I'm coming to the party late, but 👍 :) |
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:
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.