txZMQ object responsibilities about txzmq HOT 5 CLOSED

Sorry for being too slow to respond, just got back from the trip. Please give some time to think about that...

from txzmq.

Sure thing!

Again, whatever you want to do is cool. No pressure.

from txzmq.

I was looking into the changes from your pull request while trying to understand what is the best way to make ZMQ part of Twisted. txZMQ started as a quick hack to make ZeroMQ available to Twisted application.

What I was based upon:

• we don't need any kind of ZeroMQ reactor, as we can use any existing to poll on ZMQ fd
• ZMQ socket semantics is much more complex compared to TCP/UDP socket
• as ZMQ handles reconnects, there's no real requirement to put complex logic around connect/disconnect, as usually it connects only once on application startup
• particular socket type may require 'subclasses', as we don't want users to deal with raw send/recv
• some ZMQ socket types won't work well in async program, like REQ/REP, because of strict requirement to send REPly immediately after receiving REQuest (even though XREQ/XREP works fine).

I would love to see txZMQ as simple as possible for the developer.

Even though I'm using Twisted for more than 4 years, I'm still not completely in Twisted terminology/abstract classes (probably because documentation is not that complete?). I really like the direction you're heading with the changes, but I don't feel that I'm an expert. Would it make sense if I add you to this GitHub repo? I would be glad to do testing and provide review/feedback, but I feel it would be better for you to drive through this change.

from txzmq.

Thanks for taking the time to write up such a nice response :-)

I would love to be added to the GitHub repo, and I'd enjoy working on the changes in a peer-review environment (those are always the most fulfilling ones!).

from txzmq.

Thanks, Duncan! Added you to the repo.

from txzmq.