Skip to content
This repository has been archived by the owner on Apr 24, 2020. It is now read-only.

[WIP] node-zmq 3 #516

Open
wants to merge 14 commits into
base: master
Choose a base branch
from
Open

Conversation

ronkorving
Copy link
Collaborator

@ronkorving ronkorving commented Apr 19, 2016

Hopefully, this makes things a bit more sane.
Please note that this would be a major version bump to 3. We will still need to maintain node-zmq 2 for a while (bugfixes), so we should create a 2.x branch off of master before merging this.

Closes #515
Closes #438
Closes #279
Closes #175

Changes:

  • All APIs are now documented in the readme.
  • The module exports no longer is the binding. The binding is now on exports.binding. Users shouldn't need it, but there's no real need to hide it either.
  • All hardcoded constant lists removed from JS, all now come straight from C++ and feature detection. That means: socket types, send-flags, socket options, context options.
  • All number referred constants removed from C++. All constants are registered by name now.
  • All constants may be referred to by their string version (eg: "ZMQ_SUBSCRIBE") or by their lower case version with the "zmq_" prefix removed (eg: "subscribe").
  • Alias for getsockopt/setsockopt to simply get/set on the Socket class.
  • All constants are removed from the module exports. No more zmq.FOO_BAR. All getters and setters are gone. That means you now have to use get(sockopt) and set(sockopt).
  • Exposed zmq.contextOptionExists(option), zmq.socketOptionExists(option) and zmq.socketTypeExists(type) functions.
  • Context is now a proper JS class, and custom contexts can be created and configured.
  • Sockets can now be created from a context, or still straight from the module (using the default context).
  • Some style fixes and added some zmq_ return code < 0 checks that were missing.
  • Maintained support for Node >=0.10 <=5, and ZMQ >=2 <= 4.1.
  • Removed legacy send/receive methods from C++ that were no longer used.
  • Updated all unit tests.
  • probably more...

TODO:

cc @kkoopa @reqshark

@ronkorving ronkorving changed the title This refactors options, binding exposure, and more [WIP] This refactors options, binding exposure, and more Apr 19, 2016
@ronkorving ronkorving changed the title [WIP] This refactors options, binding exposure, and more [WIP] node-zmq 3 Apr 19, 2016
if (zmq_term(context_) < 0) throw std::runtime_error(ErrorMessage());
int rc;

while (true) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

do we need the while loop here?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, for EINTR

return Nan::ThrowError(ErrorMessage());
}
break;
}
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IncomingMessage was already doing the init.

@reqshark
Copy link
Contributor

pretty impressive cleanup to MessageReference class, i defer to @kkoopa for review there

(outside my pay grade)

@ronkorving
Copy link
Collaborator Author

MessageReference I didn't really touch. I just moved it. But yes, lots of things pertaining to native code have been touched or changed, so @kkoopa's review would be most welcome.

@@ -29,7 +29,7 @@ describe('proxy.xrep-xreq', function() {
req.connect(frontendAddr);
rep.connect(backendAddr);

req.on('message',function(msg){
req.on('message',function (msg) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

space btwn comma and function

@eljefedelrodeodeljefe
Copy link

eljefedelrodeodeljefe commented May 7, 2016

Deifinitely makes the module more interesting. Good effort.


### Constants

ZeroMQ is full of constants for various that are [well documented](http://api.zeromq.org/). It would be overkill to
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

*for various what?
TODO: fix

@ronkorving
Copy link
Collaborator Author

ronkorving commented Jun 13, 2016

@kkoopa @reqshark @ralphtheninja
Does it make sense if I pursue this PR before #537? That way, if that proposal is successful, we don't have to backport it and can move on with node-zmq v3. If I go with #537, the branches will drift further apart and I will have to radically update this (v3) PR as well. Perhaps limit the experimentation to v3? Does that sound good?

@kkoopa
Copy link
Contributor

kkoopa commented Jun 13, 2016

Yes, that sounds reasonable.

@ralphtheninja
Copy link

Does it make sense if I pursue this PR before #537? That way, if that proposal is successful, we don't have to backport it and can move on with node-zmq v3. If I go with #537, the branches will drift further apart and I will have to radically update this (v3) PR as well. Perhaps limit the experimentation to v3? Does that sound good?

Yep!

@ralphtheninja
Copy link

  • Maintained support for Node >=0.10 <=5, and ZMQ >=2 <= 4.1.

What about node 6?

@ronkorving
Copy link
Collaborator Author

When I made this PR, either there was no Node 6, or we didn't support it yet. Of course if I merge this, it will be in a state where it works on Node 6, no worries :)

@JamesMGreene
Copy link

Excited for many of the changes coming in this PR! 👍

@ronkorving
Copy link
Collaborator Author

Thanks :) I really need to pick it up again, have been quite busy lately.

@reqshark
Copy link
Contributor

IMO node 5 and node 6 are the same thing in terms of binding compiles... at least using [email protected]

@nicwsm
Copy link

nicwsm commented Jul 11, 2016

May I know when will node-zmq 3 be ready? Or has it already been launched?

@ronkorving
Copy link
Collaborator Author

It's not ready yet. But I'm thinking within about 2-3 weeks it should be.

@nicwsm
Copy link

nicwsm commented Jul 11, 2016

I'm also facing the same issue as #438 at the moment, but since it will require me to wait for another 2-3 weeks for the issue to be closed until version 3 comes out, may I ask if I can get any temporal help for now to get the ZMQ_IMMEDIATE issue solved?

@ronkorving
Copy link
Collaborator Author

Time is my problem right now (else I would've shipped node-zmq 3 by now) so if anyone wants to help reinvigorate #438, raise your hands please.

@nicwsm
Copy link

nicwsm commented Jul 11, 2016

@ronkorving Sure. Hopefully there are someone who will help in this, and in the meantime I'll wait for the next release. Thanks!

@ronkorving ronkorving mentioned this pull request Aug 15, 2016
@tlbtlbtlb
Copy link

To address #552 (asking to be able to share a zmq context between two different node C++ add-ins), I think the right strategy is to extract the class declarations of zmq::Context and zmq::Socket from binding.cc into a binding.h file that can be included from the other node module. They can use Nan::ObjectWrap::Unwrap<Context>(...)->context_ to get what they need (the zmq_context handle) from a JS Context argument.

I'm happy to submit a patch if people like the idea.

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

Successfully merging this pull request may close these issues.

Massive refactoring underway
8 participants