stomp-rs
stomp-rs copied to clipboard
move to tokio, fix one broken example
Hi, thanks for the PR! Skimming through the diff, it looks like much more than fixing an example -- could you describe the changes you made and why they're important?
The PR consists of two parts
- Move from deprecated
tokio-core
[1] totokio
[2]. This is a main contribution of the PR. - Fix an example to demonstrate how to use updated API. After migrating from
tokio-core
totokio
, I tried to use updated API by myself. I started from examples, but found none of the examples are working. So I decided to fix an example to show how to use updated API.
[1] https://github.com/tokio-rs/tokio-core [2] https://github.com/tokio-rs/tokio
@zslayton Any update? If there's a problem, I'm willing to submit a new patch, for example removing tokio-core
→ tokio
migration and push examples only.
@yjh0502 Sorry for the delay, I've been traveling for the last week. I'll get a chance to review this over the weekend.
Thanks for the review! I appended a commit to handle issues that addressed on the review. BTW I'm adding more changes on my fork for my own needs, and you can see commit on following links: https://github.com/yjh0502/stomp-rs/commits/master
Primary goal of those changes is make stomp-rs
usable on webassembly environment.
- make
session
to accept custom IO struct (AsyncRead + AsyncWrite + Sync + 'static
) other thanTcpStream
. - use handcrafted parser instead of
nom
, which does not work on wasm yet. I triedpest
before moving to handwritten one, but It does not support non-utf8 input. -
http
style header API. - use
rustfmt
to normalize code format
I didn't sent a PR for those changes yet because I believe those changes are quite opiniated. How do you think of sending PR for those changes?
Sorry to hijack this PR thread, but is there an effort to get modern futures/tokio support for this library and is the work done to-date (including this PR) part of that effort? Or is the library mostly OBE?
Hi, thanks for drawing my attention back to this PR. It had fallen off my radar. This PR is the only work happening on this library and I need to find the time to land it.
AFAIK there isn't another stomp
library in wide use, so getting this one back up to speed with the ecosystem would be worthwhile.
It would seem to be still worthwhile :)
@madbonkey That it would! I guess STOMP is not a protocol in too much demand with those writing services in Rust.
Seems true enough - I'd be happy to help out if there's something to do! A good library for STOMP would be nice to have, not so much for services/servers, but there's a lot of existing systems around using it and a robust client library would have an audience I think.
Mea culpa. It's been very difficult to find bandwidth for this project. 😞 Apologies to @yjh0502 for neglecting this.
When I first created it I was using a variety of MQ servers at my day job and always had one lying around to test against. (Using STOMP was a nice cross-server compatibility option, and the protocol was much simpler to implement than AMQP.)
Tokio has reached 1.0 since this PR was first opened (again, my fault!). Is anyone interested in upgrading this to the stable version?