Currently, the MAVLinkV1MessageRaw and the MAVLinkV2MessageRaw types prevent mutable access to the internal buffers they use to store the raw bytes coming from any type of connection, which is problematic for libraries that built on top of this crate.
What is actually being problematic is that this crate enforces you to use the synchronous reads (e.g read_v2_raw_message) in order to fill the raw message buffer using a reader, and there is no other way.
Building functionality over these raw packets is exclusive to the rust-mavlink library at the moment, preventing other libraries to interact with rust-mavlink in a flexible way. For example, to be able to implement a new read() function (e.g an async) for MAVLink messages from another library, access to the internal buffer of a raw message is required, which is not possible at the moment.
I highly suggest that these types somehow allow mutable access to the internal buffers.
Currently, the
MAVLinkV1MessageRaw
and theMAVLinkV2MessageRaw
types prevent mutable access to the internal buffers they use to store the raw bytes coming from any type of connection, which is problematic for libraries that built on top of this crate.What is actually being problematic is that this crate enforces you to use the synchronous reads (e.g
read_v2_raw_message
) in order to fill the raw message buffer using a reader, and there is no other way.Building functionality over these raw packets is exclusive to the
rust-mavlink
library at the moment, preventing other libraries to interact withrust-mavlink
in a flexible way. For example, to be able to implement a newread()
function (e.g an async) for MAVLink messages from another library, access to the internal buffer of a raw message is required, which is not possible at the moment.I highly suggest that these types somehow allow mutable access to the internal buffers.