-
Notifications
You must be signed in to change notification settings - Fork 62
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
Consider using msgspec library for structured message serialization #947
Comments
I think this is definitely a step up from what we currently have. Although I personally have always like the idea of some cross language specification like google protobuf that provides a json or binary format. Mainly with the idea that it would help lift a lot of the burden off people who want to make implementations that interact with the server in their language of choice. If this has that capability then definitely. Of course just having a dedicated message package with the classes listed clearly with their fields already helps with that. I know you have talked about being wary of any extra build steps which is understandable but figured I would throw it out there since this is labeled proposal. |
msgpack was discussed ~2017 and we decided to not use it. JSON is simpler to read and process across plattforms (also with outlook for web, websocket, stomp). We are not in a situation where every byte counts. |
After messing around with this library for a bit I ran into a few things that made me not want to use it:
|
Today I stumbled upon this library for doing json encoding/decoding in Python. Rewriting our message handling to use it could have many benefits, most importantly making it easier to document what the message format actually looks like as each message would become a class with explicit fields.
The Library: https://github.com/jcrist/msgspec
Features we need that it has:
This is how our message format currently distinguishes between commands.
We currently filter out
None
values in a few places by copying the message before serializing it. Having this feature built in could make the code simpler and improve performance. We would just need to see how we want to handle this with non-None default values.This can make appending the newline we need more efficient
Other features:
*Maybe a plus? I recall there was an attempt to use msgpack before because it can be a more efficient representation than JSON, however, using inefficient representations hasn't really been a problem for us in the past (see QDataStreamProtocol :P)
The text was updated successfully, but these errors were encountered: