5 ms·
I don't like the idea of everything using HTTP. I prefer ZMQ. There is a substantial work done to process all the HTTP overhead. In addition to that there is n
by j2labs 15y ago
I don't like the idea of everything using HTTP. I prefer ZMQ.
There is a substantial work done to process all the HTTP overhead. In addition to that there is no load-balancing included and it would likely be delegated to a whole new service or machine, when ZMQ could just provide this.
Instead of relying on Werkzeug and HTTP, I can use DictShield models, serialized to JSON or Python, and send those across ZMQ sockets. The ZMQ sockets don't time out, like HTTP, they are instead removed when a host goes down. PUB/SUB messaging is possible, round-robin routing. Lots of patterns instantly available.
Ease in using HTTP itself is welcome, but I don't want to use it in my infrastructure. It's a band-aid for WSGI instead of a solution.
- detst 15y agoI don't understand your point and why it's the top comment. Sure, 0MQ is great and can be used in place of HTTP in some cases. But if you want to serve requests to a web browser, you have to speak HTTP at some point. These are the use cases they are handling. It's not even a matter of preference; it's a matter of a need for HTTP and they are addressing this need, while apparently accounting for 0MQ (he mentions it in the post). Also, you mention down-thread, "HTTP is the weaker of the two transports"; it's only "weaker" if you ignore any use case that involves communicating with a web browser.
- j2labs 15y agoThe involvement of the requests library signals that the consumer is not a web browser...
- LeafStorm 15y agoNo, but it does signal that the producer is a Web server. Those aren't going away anytime soon, either.
- j2labs 15y agoAs I said before: Ease in using HTTP itself is welcome, but I don't want to use it in my infrastructure. It's a band-aid for WSGI instead of a solution.
- detst 15y agoNo, it doesn't. It signals that unifying multiple code-bases and efforts containing clear overlap is a pretty smart idea. This project will still be used to serve requests from a web browser. It will also be used to make requests to HTTP services that the user has no control over. Are you just trying to make an ideological argument that HTTP is used in cases when 0MQ might be a better option? If so, I agree but I just don't understand why you seem dismissive of this project when HTTP has its place and, therefore, this project has its place. The fact that 0MQ is mentioned in this post seems to indicate that the author understands 0MQ's place.
- j2labs 15y agoI prefer ZMQ when I have the choice. ZMQ is better from an ideological perspective and better for infrastructure. In cases where you can only use HTTP, this will be great, but if I have a choice I'd use ZMQ instead. I don't mean to sound dismissive, but I am opinionated. I think Kenneth and Armin do great work. I'm sure this project will be excellent.
- detst 15y agoI think our only disagreement is that you viewed it as a poor alternative for 0MQ and I viewed it as something else. Just a different perspective that I interpreted as taking away from what this announcement was really about but I suspect it wasn't your intention.
- someone13 15y agoSomething else worth noting: from how I understand it, 0MQ isn't safe to use over the internet. Safe in your infrastructure, inside your firewalls and such, but not over the internet. So, in terms of making, e.g. public-facing API, you don't really have a good choice except HTTP. EDIT: This is incorrect, read below.
- espeed 15y agoYou may be referring to Zed Shaw's comment in his PyCon ZeroMQ talk -- but that issue has been resolved since then.
- someone13 15y agoThanks, I didn't realize that. Specifically, this link mentions it: http://www.zeromq.org/area:faq#toc5 http://www.zeromq.org/area:faq#toc5 Appreciate the heads-up!
- jbrechtel 15y agoSeems like without SSL there are still several scenarios where a webservice over HTTPS is more appropriate?
- j2labs 15y agoYou can use TLS/SSL with ZeroMQ. The docs suggest doing so here: http://www.zeromq.org/topics:encryption http://www.zeromq.org/topics:encryption
- shazow 15y agoThis idea actually came up in our discussions. Requests will have a set of request-level adapters which will let you define the protocol you're speaking, whereas urllib3 aspires to have connection-level adapters which let you define the transport you're using. So, hypothetically once we make this a reality, you could have a ZMQ connection transport which has a JSON request adapter and happily use Requests with whatever made up scenario you like. :)
- shykes 15y agoI'm curious about the constraints this would impose on alternate transports. How similar would they have to be to HTTP? For example, zerorpc (http://github.com/dotcloud/zerorpc-python http://github.com/dotcloud/zerorpc-python) supports a request-response pattern (using ZMQ REQ/REP), and can return a stream as a response. That maps nicely to http, and I could see that "mounted" as a mock http endpoint which is very interesting. But there are lots of features in zerorpc that I'm not sure how to map to an http library. For example: * zerorpc methods must expose positional arguments; how would that map to http query arguments? * zerorpc arguments can be arbitrary data structures. * zerorpc has no notion of headers. * etc. I'm excited at the idea of making cross-transport interop easier. At the same time I wonder if the mold of "HTTP-ness" might stifle the ability to think outside the box when designing a transport?
- shazow 15y agoKeeping in mind that with zerorpc, you control both the client and the server, none of this should be a problem. You can have positional http query arguments (?foo=1&bar=2) as long as you can guarantee that both the client and server treat them as such (not the case with web browsers, obviously). Either way, it'd be great if we had a big list of possible use cases we'd want to support to keep in mind as we're designing this. Anyone want to start one? :D
- j2labs 15y agoI think it would be pretty cool to hook Brubeck up to ZeroRPC. Brubeck can do all the web processing and then communicate with Mongrel2 for HTTP while delegating other work through ZeroRPC.