Hi James, Thanks for your response! Replies inline.
On 02 Sep 2014, at 18:53, James Reeves <ja...@booleanknot.com> wrote: > Ring uses blocking I/O by default, because that's often sufficient for most > web servers, and is generally easier to reason about. HTTP works best when > the response is returned ASAP, which means blocking I/O typically isn't much > of a bottleneck. > > However, since Ring 1.2, all of the standard middleware has also been > available to use asynchronously, in order to support frameworks like > Pedestal. So it's certainly possible to use Ring in an async environment, at > least with the core Ring libs. > > Although HTTP Kit doesn't use core.async channels itself, the async protocol > used isn't complex. You should be able to hook up core.async/take! to > http-kit/send!. Something like: > > (defn handler [req] > (httpkit/with-channel req http-ch > (let [resp-ch (async-handler! req)] > (httpkit/on-close (fn [_] (a/close! resp-ch))) > (a/take! resp-ch (fn [resp] (httpkit/send! http-ch resp) > (httpkit/close http-ch)))))) That’s what I wanted to do, but then I saw the warning on http-kit’s website at http://http-kit.org/server.html#channel , which states: Data is sent directly to the client, NO RING MIDDLEWARE IS APPLIED. … which leads me to believe that the send! API just totally sidesteps any middleware, and it’s not so much up to the middleware whether or not it supports asynchronous operation. Unless of course it actually works fine, and that’s simply some stale documentation? > That said, I'd be wary about having HTTP clients wait around on the server. > If it's just a few seconds, that seems reasonable, but any longer and you > should consider redirecting to a "job" resource instead. Yeah, I’ve been considering that. Looking at the distribution of response times right now, > 5-10s is a small, but non-negligible part of the responses. However, the point of this software is being able to give third parties capabilities (in the object-capability sense), so typically some of the requests involve secrets the caller doesn’t get to know about (like API credentials). As a result, I’m trying to be hyper-conservative in terms of stuff that can leak information. I’ll have to think more about that one :-) hth lvh
signature.asc
Description: Message signed with OpenPGP using GPGMail
