-
Notifications
You must be signed in to change notification settings - Fork 14
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
wip: update to embedded-io #39
Conversation
I have released buffered-io v 0.2.1 that now works with embedded-io 0.5. |
For embedded tls i went with propagating it https://github.com/drogue-iot/embedded-tls/blob/main/src/lib.rs#L138-L139 But for buffered.. maybe its ok with zero? |
Year, in your case you already have a custom error type in which you can have a variant where the case can be assigned to. I do not have that in my case, as the error type is transparent to the buffering layer. I can see multiple places where this new error type can cause annoyances. I am really uncertain what the best way to handle this case is. |
Right now I simply ignore the error and discard the currently buffered bytes which is clearly not correct. |
Hmm, yeah, that is problematic. I guess there is no way around creating an error type specific to buffered-io then? Or maybe it would help if ErrorKind had a variant for WriteZero so that it WriteAllError could provide a kind() ? |
I have now released buffered-io v. 0.3 which now fixes the outstanding issue where the WriteAllError::ZeroWrite error variant is ignored. It however adds a constraint on the error type to the below transport: https://github.com/rmja/buffered-io/blob/master/src/asynch/write.rs#L29-L30. This is really annoying, as it kind of cascades up to the consumer. I have tried to align reqwless to this change, and it seems to add a-lot of constraints all over the place. For tests that uses Vec as a transport, this also requires rust-embedded/embedded-hal#491. I have looked at e.g. https://github.com/MabezDev/embedded-fatfs for comparison. It does something similar to circumvent this, but it is really annoying to work with. |
I think that the |
Agreed, thanks for following up on that! |
buffered-io v 0.4 is now released implementing embedded-io 0.6, hence this should not block any further work here. |
Continued in #41 |
@rmja Currently awaiting rmja/buffered-io#1