3 ms·
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
by 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 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.