Skip to content
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

State of this project? #164

Open
paddor opened this issue Jan 27, 2025 · 1 comment
Open

State of this project? #164

paddor opened this issue Jan 27, 2025 · 1 comment

Comments

@paddor
Copy link

paddor commented Jan 27, 2025

I just took a look at this gem as a candidate for a future project. I noticed a few things.

  • Is this gem still maintained?
  • Methods like Client#connect create Threads. Are there plans to disable this to make it better usable in a Ruby Async environment?
  • TCP_NODELAY does not seem to be enabled on the TCP socket
  • Have you considered using bindata for the packet serialization/deserialization code?

Thanks.

@njh
Copy link
Owner

njh commented Feb 3, 2025

Hi!

  1. Yes, it is sort of maintained. I have been a bit short of time in recent years.
  2. The API design is not very asynch compatible. I did create an EventMachine API but didn't find it very reliable. I suspect that it might be better to build a new gem with a new API. Note that that is paho.mqtt.ruby, which has an API similar to Python. It uses my packet parsing code.
  3. I would welcome a patch that adds TCP_NODELAY to this library
  4. I was not aware of the BinData ruby gem. It looks pretty nice. How does it perform compared to #pack and #unpack?See also Support for MQTT 5 #162

See also #162 (add support for MQTT v5). I think the first step would be to separate out the packet parsing / serialising code into a new gem.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants