Offering a nicer API on std

[wucke13]

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]

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]

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]

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

[wucke13]

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]

Yes! std shall be optional!

I am totally fine with that