

Make HTTP requests over ZeroMQ with Zurl - jkarneges
http://blog.fanout.io/2012/09/26/make-http-requests-over-zeromq-with-zurl/

======
tlrobinson
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
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
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
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.

