Control protocol content header: message type #53
Description
Main issue: #41 , also related to #29
In #41 we basically came to the conclusion, that we include some message id and the message type in the header.
This issue is about the message type information.
One idea was, to include here the message type (any from the collection in #29).
Another idea is, to include just the format (json, binary, avro...) of the following content frames, in order to decode the correctly.
A third idea is, that this message type information could indicate any of the messages of the control protocol itself (sign in/out, heartbeat, certain error messages) or the format of the content frames (json, binary...).
That would allow to separate more easily between messages meant for the protocol part (heartbeat, sign_in/out, errors...) and RPC calls or other information for the application layer (getting/setting something).