Offering a nicer API on std

msp-rs / multiwii_serial_protocol_v2.rs

A Multiwii Serial Protocol (MSP) implementation for Rust

4 stars 2 forks source link

Offering a nicer API on std #10

Open wucke13 opened 4 years ago

wucke13 commented 4 years ago

Hi, what do you think of offering a nicer API for std builds? My ideas so far:

offering an API which turns anything which offers Read & Write into a MSP Connection:

pub trait MspConnection: Read + Write {}
impl<T: Read + Write> MspConnection for T {}

Having a fetch method on the MspMessage Type itself, hence one can use code likes this, getting rid of matching against a variant of an enum with all messages:
```
let my_message: MspAttitude = MspMessage::fetch(msp_conn)
```
Having a fetch method on the MspConnection as well, which returns an enum MspMessages
Offering an async interface. (This I don't know yet how to make it nice)

This are just some quick ideas of my head, what do you think about it?

amfern commented 4 years ago

I like the idea.

I guess for sync-std we can offer another trait

pub trait MspConnectionAsync: async_std::io::Read + async_std::io::Write {}
impl<T: async_std::io::Read + async_std::io::Write> MspConnectionAsync for T {}

but then the library will dependent on std and async-std and won't compile at all for no_std, right? do we want to support not_std at all?

maybe we should use the serde.rs trait also, https://docs.serde.rs/serde/ser/trait.Serialize.html after all its a serialization library. because its already covers the Write & Read traits

wucke13 commented 4 years ago

The idea of using serde is interesting, indeed. Though replacing rudis struct de-/ser code will be a massive task. First I want to think about how async request shall work though, I'm still not at a point where I have a presentable solution.

amfern commented 4 years ago

Actually Rudis code used packet_struct library, which already uses serde, the Serialize and Deserialize are coming from there. So ignore my comments :)

wucke13 commented 4 years ago

Too bad that all of rudis stuff is not maintained. Like, for many that's a no-go. @rudib if you read this, please consider to at list add your crates to the bus.

do we want to support not_std at all?

Yes! std shall be optional!

amfern commented 4 years ago

Yes! std shall be optional!

I am totally fine with that