Open wucke13 opened 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
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.
Actually Rudis code used packet_struct library, which already uses serde, the Serialize and Deserialize are coming from there. So ignore my comments :)
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!
Yes!
std
shall be optional!
I am totally fine with that
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: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:
Having a fetch method on the
MspConnection
as well, which returns anenum 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?