3 ms·

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, where

by shazow 15y ago

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

shykes 15y ago
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 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 ago
  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
  - j2labs 15y ago
    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.

by shazow 15y ago

shykes 15y ago

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 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 ago
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
- j2labs 15y ago
  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.