4 ms·

Make HTTP requests over ZeroMQ with Zurl

35 points by jkarneges 14y ago

tlrobinson 14y ago
Nice. Does it use exactly the same protocol as Mongrel2? i.e. if I point Mongrel2 at Zurl is the result a transparent HTTP proxy? If so, that's really cool. Having symmetric client and server APIs is awesome because you can reuse identical middleware. e.x. say you have "Cache" middleware: cachingClient = Cache(client) cachingServer = Server(Cache(yourApp)) cachingProxy = Server(Cache(client)) EDIT: Also, why the heck does it depend on QT? :-/
- jkarneges 14y ago
  Sharing the protocol with Mongrel2 would be highly amusing. :) The reason it doesn't is because having to use Mongrel2's request format wouldn't be very intuitive from a user's perspective. Zurl accepts a verb and URL as input, which I think is the most straightforward. I wouldn't be opposed to Mongrel2 compatibility though, if it was done in some optional way, such as maybe detecting the input format. Dealing with uploaded temp files may also be a little awkward. While Zurl's protocol is inspired by Mongrel2, I did take some liberty in tweaking it for the better (e.g. streaming in both directions without needing files, and packet sequence numbers). And Qt is great. :) Zurl only depends on the core and network libs.
  - vog 14y ago
    Indeed, Qt is a great C++ API, although its design style is quite different from STL, boost and friends. In particular, Qt is a very good example of a well-designed exception-free API. That is, it doesn't make any use of exceptions, and yet you don't have to check for error code after each low-level operation. For almost every class, Qr provides sensible "null-like" objects, i.e. they don't simply return stuff like NULL pointers, or JavaScript-like "null" objects that crash a bit later (when you try to access properties). You just get an object that behaves sane to the most possible extent, so mostly it simply doesn't matter to your code that some operation returned a null-like object. And in those rare cases where it does, you usually have to check later, and only once, in your code. You don't have to check after every single step. This is quite hard to describe, but I think that sensible null-like objects make it possible to combine all advantages you usually get from using exceptions, without the disadvantages that arise from disrupting your control flow (which would make it harder for you to reason about your code and to ensure proper cleanup after each operation). All in all, the Qt API taught me a lot about design concepts you usually don't find in other APIs.
prodigal_erik 14y ago
This puts a process boundary between my HTTP stack and the rest of my app. I know some people want to do that, but I've never understood why.

35 points by jkarneges 14y ago

Nice. Does it use exactly the same protocol as Mongrel2? i.e. if I point Mongrel2 at Zurl is the result a transparent HTTP proxy? If so, that's really cool. Having symmetric client and server APIs is awesome because you can reuse identical middleware. e.x. say you have "Cache" middleware: cachingClient = Cache(client) cachingServer = Server(Cache(yourApp)) cachingProxy = Server(Cache(client)) EDIT: Also, why the heck does it depend on QT? :-/

jkarneges 14y ago
Sharing the protocol with Mongrel2 would be highly amusing. :) The reason it doesn't is because having to use Mongrel2's request format wouldn't be very intuitive from a user's perspective. Zurl accepts a verb and URL as input, which I think is the most straightforward. I wouldn't be opposed to Mongrel2 compatibility though, if it was done in some optional way, such as maybe detecting the input format. Dealing with uploaded temp files may also be a little awkward. While Zurl's protocol is inspired by Mongrel2, I did take some liberty in tweaking it for the better (e.g. streaming in both directions without needing files, and packet sequence numbers). And Qt is great. :) Zurl only depends on the core and network libs.
- vog 14y ago
  Indeed, Qt is a great C++ API, although its design style is quite different from STL, boost and friends. In particular, Qt is a very good example of a well-designed exception-free API. That is, it doesn't make any use of exceptions, and yet you don't have to check for error code after each low-level operation. For almost every class, Qr provides sensible "null-like" objects, i.e. they don't simply return stuff like NULL pointers, or JavaScript-like "null" objects that crash a bit later (when you try to access properties). You just get an object that behaves sane to the most possible extent, so mostly it simply doesn't matter to your code that some operation returned a null-like object. And in those rare cases where it does, you usually have to check later, and only once, in your code. You don't have to check after every single step. This is quite hard to describe, but I think that sensible null-like objects make it possible to combine all advantages you usually get from using exceptions, without the disadvantages that arise from disrupting your control flow (which would make it harder for you to reason about your code and to ensure proper cleanup after each operation). All in all, the Qt API taught me a lot about design concepts you usually don't find in other APIs.

prodigal_erik 14y ago

This puts a process boundary between my HTTP stack and the rest of my app. I know some people want to do that, but I've never understood why.