Discussion: Improving the API

[wucke13]

Discussion: Improving the API

[wucke13]

The interest in discussing this seems to be on a moderate level at best. I released some of the proposed changes in an independent crate on crates.io. I would still be happy to have this discussion though, as there are quite some big compromises on my crate due to some limitation of the mavlink library.

[patrickelectric]

Hi @wucke13, sorry for not being able to help much about this matter, but I was planning to create an actor based communication method over mspc, that appears the correct way to accomplish it.
I started the implementation but since I'm out of time I was unable to finish it.

Don't you want to create a PR to add the async functionality in this repository ?

[wucke13]

Yeah, I'm still happy to merge my code. However, now that I released to an independent crate, I would like to use the opportunity to refine things more. I wan to add some convenience functions (like send message a, until the first message b arrives) for dealing with unreliable communications.

My strongest desire which AFAIK can not be solved outside of this crate would be an implementation of

TryFrom<::Message> for ::PLACEHOLDER_DATA. So a generic way of converting any message into a specific message struct without explicit matching. Can you add this?

[patrickelectric]

TryFrom<::Message> for ::PLACEHOLDER_DATA. So a generic way of converting any message into a specific message struct without explicit matching. Can you add this?

From what I know this is not possible directly and a generic tryfrom will need to be implemented, and I don't see a reason for this.
What is necessary IMO is to recreate the parser and deal with the parsing to be async, that's what I'm doing with my patch plus the async communication with mspc.
You can check that in my open draft PR here: #79

[wucke13]

I don't see a reason for this

Well, here is one: This is necessary to offer a sane API where the user receives filtered messages (e.g. only one message type). If I and a stream both now that said stream will only yield PARAM_VALUE messages, than it would be very nice for the stream to be able to directly return PARAM_VALUE_DATA structs. Currently, there is no way to offer such an API, for the reasons stated in my initial posting. Does this make sense to you, or shall I try to explain in more detail why I think that there is a strong reason for that?

From what I know this is not possible directly

Why is that? It's not possible in a generic way, because there is (IMHO major) problem in the TryFrom implementation from the std library (more details). However, with the information about all variants (which only this library has in it's build script) available at the code level, it is:

I thought one way would be this:

• to every enum MavMessage add a function in the impl which
  • matches against every possible variant
  • unpacks the contained data
  • casts a reference counted reference of it to Any
  • and returns this any
• Add this as_any function to the Message trait.
• Than on the Message trait, add a try_extract<T>(&self)->Option<T> function.

Do you see a problem with this approach, implementation wise? I'm sure there is more elegant ways of doing it, but I did not think of any so far.

Also, whats the point with channels when going the async route? I don't understand why you would be doing both.

At least the discussion started now 😄

[wucke13]

@patrickelectric Ping

Also: if this helps, I'm open to hop on a virtual meeting to discuss this issue further. However that's just an idea.

[patrickelectric]

Hi @wucke13, sorry I'm in a complicate period in the last days, will try to catch-up with this discussion when possible.

[wucke13]

@patrickelectric As stated before, I'm open to any means of digital communication, at your choice. Until then: take your time and good luck!