Replace protobuf with flatbuffers #494
Description
Flatbuffers replaces protobuf (because of overhead and major upgrade required to be future proof again). Controlling (clear/clearll/setEffect/...) shouldn't be handled at the interface (at least for the moment) it's meant to be used for sending a lot of data more efficient compared to plaintext json (webserver/websocket)
Connection: Clients needs to keep the connection open to register once with meta data, followed by the real data. A connection abort of the tcp socket means register again
Register message:
Hyperion.ng makes more use of meta data, so it's probably better to send them just once on new connection. (This is also the new internal pattern to reduce data passing and to make it more readable)
- origin User friendly name of the sender
- priority Priority to use, the priority will last for the current socket connection to assign the send data to this priority
Data fields proposal (send to push data):
- type (int) Type of data to support different formats. As Hyperion is probably faster to "decode" data to the Hyperion format compared to a client. (Example RGB, RGBA, jpeg/png as base64, ...)
- data The data will be processed according to type
- width (optional) Depends on type, the current data type in protobuf requires it while other types in future may not
- height (optional) Depends on type, the current data type in protobuf requires it while other types in future may not
Dropped fields compared to protobuf:
- timeout There is no reason why the client should provide a timeout. This should be handled by Hyperion/ user settings for the flatbuffer receiver. Allows more control as not sending clients can be disconnected automatically after a specific period along with their priority registration.
- All control fields.
@MartB
Please leave a comment, probably i've overseen something. If you have questions just ask.
issue: #455