-
Notifications
You must be signed in to change notification settings - Fork 31
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
ZAP #18
Comments
It's sounds a good starting point. For the broker having a callback to authenticate connections is perfect. Thank you |
@prdn Yes I think we should pass them in the client and worker I actually hard coded them in my testing, but we can make it configurable. I find passed the call back in the configuration clumsy and was wondering if we should have a build in zapHandler that would be overridden before calling start on the broker. As you guys think its a good start, I'll fork the repo and make the changes. Do you guys have a coding style guide i need to follow? |
@leonpegg Not actually a coding style guide. Thank you for your help. |
Thats sounds good I'll polish off some code later today. |
Ok basic implementation of zmq-zap is available here. https:/leonpegg/pigato/commit/585f7fc26bf7f95bef6bd9649b57834986a576a2 opinions welcome. |
fixed examples to so now works https:/leonpegg/pigato/commit/a945ada06d2dcd7fc556041170c9ad241cbe6044 |
I know adding zap support is on the roadmap and that zmq-zap is still in the unstable state, But I would like to give a crack at implementing it.
I have a basic PLAIN and NULL implementation working and have been using it in production.
I would like to know if you have any recommendations for implementation, my current method is to configure the broker as the zap server passing a zap object in the config which also includes the zapHandler and passing zap: true on the config of client and worker.
If you have any better suggestions please let me know.
The text was updated successfully, but these errors were encountered: