rumqttd
rumqttd copied to clipboard
tekjar
Is the broker released as a separate library?
Thanks for this work, it would be great if you could publish this as a library as well - any thoughts on that?
@opensourcegeek Hi. I didn't completely understand why you need this as a library. Do you want me to segregate reusable parts to create mqtt client libraries? Please explain me your use case
@tekjar Mainly to embed in another application. I know I can run this as a standalone broker and then subscribe from my application. However it would be much simpler (or easier) to deploy one application which has the broker embedded in it. I deploy these applications in proprietary (network) devices and there are few thousands of them, managing deployments to these remote devices with a lot of binaries is a struggle. My approach was going to be, embed the broker in sample application which can gather data from other clients (publish data) and push it to another central server which runs one of the pub/sub solutions like Google's Cloud pub/sub or the likes. Even though broker runs within same application i would start broker in a separate thread and I'd still subscribe to events from other threads to push it upstream I guess - may be it's a bad idea. Any suggestions?
Also, for custom needs such as authentication for pub/sub, it kind of makes sense to offer a library (or at least an auth plugin system)
On Wed, Sep 13, 2017 at 1:38 PM opensourcegeek [email protected] wrote:
@tekjar https://github.com/tekjar Mainly to embed in another application. I know I can run this as a standalone broker and then subscribe from my application. However it would be much simpler (or easier) to deploy one application which has the broker embedded in it. I deploy these applications in proprietary (network) devices and there are few thousands of them, managing deployments to these remote devices with a lot of binaries is a struggle. My approach was going to be, embed the broker in sample application which can gather data from other clients (publish data) and push it to another central server which runs one of the pub/sub solutions like Google's Cloud pub/sub or the likes. Even though broker runs within same application i would start broker in a separate thread and I'd still subscribe to events from other threads to push it upstream I guess - may be it's a bad idea. Any suggestions?
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/rumqueue/rumqttd/issues/11#issuecomment-329289741, or mute the thread https://github.com/notifications/unsubscribe-auth/AAHlC9DBtLpgatXgT8rppzJ5u75e1fYWks5siD07gaJpZM4PS4eG .
@opensourcegeek @rrichardson Makes sense. I'll plan for that eventually. My first goal for this crate is to segregate broker/clients state & IO. But right now my focus is on new async client. I'm trying to make it as easy to use as possible. Efficiency is also a priority. Since there is a bunch of code that can be shared between broker and client I'll finish that first and apply what I learnt here.
@opensourcegeek Hi sorry. I'm hardly getting any time to work on this.
I thought to keep this project on hold since I feel that I'm putting a lot of work in understanding tokio and dealing with huge hard to read errors. I think I'll start this once async/await is stable.
@tekjar No problem at all - I'm on same boat, trying to get into details of tokio so I completely understand. I was going to try this on server but we made decision not to (at least for now). Thanks for the update.