stomp-rs icon indicating copy to clipboard operation
stomp-rs copied to clipboard

move to tokio, fix one broken example

Open yjh0502 opened this issue 6 years ago • 11 comments

yjh0502 avatar Oct 08 '18 14:10 yjh0502

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?

zslayton avatar Oct 09 '18 02:10 zslayton

The PR consists of two parts

  • Move from deprecated tokio-core[1] to tokio[2]. This is a main contribution of the PR.
  • Fix an example to demonstrate how to use updated API. After migrating from tokio-core to tokio, 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

yjh0502 avatar Oct 09 '18 03:10 yjh0502

@zslayton Any update? If there's a problem, I'm willing to submit a new patch, for example removing tokio-coretokio migration and push examples only.

yjh0502 avatar Oct 19 '18 07:10 yjh0502

@yjh0502 Sorry for the delay, I've been traveling for the last week. I'll get a chance to review this over the weekend.

zslayton avatar Oct 19 '18 18:10 zslayton

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 than TcpStream.
  • use handcrafted parser instead of nom, which does not work on wasm yet. I tried pest 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?

yjh0502 avatar Oct 22 '18 09:10 yjh0502

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?

jnicholls avatar Apr 29 '19 20:04 jnicholls

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.

zslayton avatar Apr 30 '19 13:04 zslayton

It would seem to be still worthwhile :)

madbonkey avatar Feb 28 '21 12:02 madbonkey

@madbonkey That it would! I guess STOMP is not a protocol in too much demand with those writing services in Rust.

jnicholls avatar Feb 28 '21 12:02 jnicholls

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.

madbonkey avatar Feb 28 '21 13:02 madbonkey

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?

zslayton avatar Mar 02 '21 14:03 zslayton