Ryan Summers

> The downside being, that if the packet is actually in my circular buffer, but half of it is wrapped around, i would never be able to read it. That's...

The problem is that if we make a separate trait, we have now divided the ecosystem. If a library required a zero-copy stack, then it would not be usable with...

That's a potential avenue as well - it would be very reasonable to add zero-copy APIs, but then force the implementation of the traits to internally buffer if the underlying...

Question: Are you trying to write a TFTP client or a TFTP server? A TFTP client in an embedded context is _usually_ some PC where someone is trying to write...

This may come down to the implementation of `std-embedded-nal` as well, but my reading shows that the duplicate `connect()` _should_ result in a new `bind` call to the updated port:...

Ah indeed I was mistaken. When trying to implement a "TFTP Client", you need to (confusingly) implement UDP server traits. ```rust // Send a TFTP request to a server let...

Now that https://github.com/drogue-iot/embedded-tls exists, I'm actually quite interested in leveraging TLS for devices running MQTT, and it seems to me like different traits are required for this. For an MQTT...

I have not had the opportunity to dive into async Rust yet, so I don't know if I can have much valuable input for async traits. I've been leaving the...

> I think they absolutely need to be specific on a per-socket basis to be even remotely useful. Think about a super simple setup, where my IoT device needs to...

Right now, the current solution to this would be to just return a `TcpSocket` as a result of `connect()` that is not in the connected state (e.g. calling `is_connected()` would...