PR or Fork?

[jkoplo]

I stumbled upon this project after having some headaches connecting C implementations of the MQTT client with LabVIEW Realtime. I forked it intending to PR my changes, but honestly I've refactored a lot of the code and I'm not sure if you'll want it or not. It would definitely be a breaking change to any existing installs you have.

Highlights:

• All messages (datagrams) inherit from a base message class
• A lot of reorganization in terms of when the datagram is actually turned into a binary packet
• Mostly removed the notifier - most user functions are now async (may add synchronous calls back in)
• Removed the LV2 globals that were being used for configuration - now holding config in the private data for the MQTT class (necessary for multiple instances)
• Made most class VIs private instead of public
• Message ID moved to non-user code
• All user functions (Send/Subscribe) now require a class instance
• The connection is auto-reconnected if it's broken

A lot of this was to make MQTT suitable to match up with some other internal communications libraries (TCP/UDP/UDP Multicast). There's actually some other wrappers I've built above this library that I'm not sure if I should include or not around JSON formatted messages and multiple queues receiving a copy of a message.

Let me know if you want me to PR all this back to you or if it would be better to rename my fork and carry it forward as it's own implementation.

[jkoplo]

Oh and it's in LV2020, because implementing TLS is high on my requirements list - though I haven't finished that up yet.

[jkoplo]

Also I apologize for the PR on your origin. Github keeps defaulting to want to merge back to your master instead of my branched master. I'm not used to the workflow on a repo I don't have commit privileges.

[cowen71]

Hi jkoplo, Unfortunately, I am not getting the time to support this development further. However, I am very happy that you are progressing and improving this.

No apologies needed. Kind Regards