Hacker News Reader

Comment by j2labs | Hacker News Reader

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.

View on HN

I 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.

The involvement of the requests library signals that the consumer is not a web browser...

No, 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.

I 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.

I 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.

No, but it does signal that the producer is a Web server. Those aren't going away anytime soon, either.

As 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.

This 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. :)

I'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) 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?

Keeping 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

I 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.

Something 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.

You may be referring to Zed Shaw's comment in his PyCon ZeroMQ talk -- but that issue has been resolved since then.

Thanks, I didn't realize that. Specifically, this link mentions it:

http://www.zeromq.org/area:faq#toc5

Appreciate the heads-up!

Seems like without SSL there are still several scenarios where a webservice over HTTPS is more appropriate?

You can use TLS/SSL with ZeroMQ. The docs suggest doing so here: http://www.zeromq.org/topics:encryption

Reply on news.ycombinator.com