Just an FYI (to those interested, eg @kkoopa, @reqshark).
I'm completely refactoring what we export, as it's such a complete and utter mess right now, I want to prepare you for what's coming:
Removal of all constants on module.exports
Yes, all constants are gone. This is relevant, because some constants actually conflict with API (subscribe and unsubscribe for example are socket options, but also API). As ZMQ gets more and more socket options, this has become an unmanageable mess. Time for some clean up. That means that people will have to use getsockopt and setsockopt to access options. They may still use shorthand (last_endpoint) and full constant string names (ZMQ_LAST_ENDPOINT), as well as the actual integer representing the option.
No more module.exports = zmq; // the binding
The binding should be wrapped, not infested with all kinds of separate API.
A rewrite of how defined constants are registered
Currently, they're stored by number. In the upcoming PR they will be:
#ifdef ZMQ_LAST_ENDPOINT
OPT(binary, ZMQ_LAST_ENDPOINT);
#endif
This macro will inject it into opts_binary and JS land: zmq.options (string -> int). All the options are gone from JS land. It's all driven from C++. JS just exposes it.
I'm taking this opportunity to add all missing options (there are a few).
Once all this is done, this will obviously mean major version bump.
Just an FYI (to those interested, eg @kkoopa, @reqshark).
I'm completely refactoring what we export, as it's such a complete and utter mess right now, I want to prepare you for what's coming:
Removal of all constants on module.exports
Yes, all constants are gone. This is relevant, because some constants actually conflict with API (
subscribeandunsubscribefor example are socket options, but also API). As ZMQ gets more and more socket options, this has become an unmanageable mess. Time for some clean up. That means that people will have to usegetsockoptandsetsockoptto access options. They may still use shorthand (last_endpoint) and full constant string names (ZMQ_LAST_ENDPOINT), as well as the actual integer representing the option.No more
module.exports = zmq; // the bindingThe binding should be wrapped, not infested with all kinds of separate API.
A rewrite of how defined constants are registered
Currently, they're stored by number. In the upcoming PR they will be:
This macro will inject it into opts_binary and JS land:
zmq.options(string -> int). All the options are gone from JS land. It's all driven from C++. JS just exposes it.I'm taking this opportunity to add all missing options (there are a few).
Once all this is done, this will obviously mean major version bump.