3 ms·

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

• LeafStorm 15y ago
  No, but it does signal that the producer is a Web server. Those aren't going away anytime soon, either.
  • j2labs 15y ago
    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.
• detst 15y ago
  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.
  • j2labs 15y ago
    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.
    • detst 15y ago
      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.