chris m

Work has been started for this in the `topics` branch; right now, the TCP test is working, UDP is failing, and QUIC is not yet implemented. This is also demonstrating...

I agree. I was also thinking about, at least temporarily, trying to replace this with `spawn_blocking` per [this thread](https://users.rust-lang.org/t/tokio-from-async-to-sync-and-back-to-async-block-on-vs-spawn-blocking/83438) to see how that goes, although I'm not sure it will...

Starting to play around with different approaches for this in the `async_split` branch

So it turns out that splitting async and sync code, and patterns for doing so, is not some kind of novel problem. Per [this](https://stackoverflow.com/questions/75656227/avoid-duplicating-sync-and-async-code-in-rust-library) Stack Overflow thread libraries like `reqwest`...

@fgadaleta This doesn't necessarily address your `block_on` issue, but I've been toying around with trying to solve some potential Tokio conflicts by making it optional for Nodes to own their...

This is being worked on in #64 via the [`async`](https://github.com/quietlychris/meadow/tree/async) branch

It's definitely not what I want! Honestly, that bit of code basically falls into the "make it compile" bucket. I'm planning on doing a complete overhaul of the error handling...

This has begun to be addressed in [2e2e4e7](https://github.com/quietlychris/bissel/commit/2e2e4e7e20371dec5bc80892b4d84abe88a51c94), but definitely still some work to do on that handling that ack so that it's not just a `String` return.

@gilescope I know it's been ages since you looked at this, but I've been slowly chipping away at trying to improve this library. If you'd be interested/willing in taking a...

Thank you :) My understanding from https://tokio.rs/tokio/topics/bridging is that calling `block_on` is basically necessary for moving the result of an async networking call back into synchronous code. Even in the...