To clarify, I didn't mean gary's last snippet. I meant this could
work with the linked Ring middleware:
(defn aleph-to-ring-handler [req]
(respond! req (ring-handler req)))
as would the variation David's been using for his "hello world"
benchmarks:
(defn aleph-to-ring-handler [req]
(future
(respond! req (ring-handler req)))
On Jul 21, 12:06 pm, Zach Tellman <ztell...@gmail.com> wrote:
> On Jul 21, 11:51 am, David Nolen <dnolen.li...@gmail.com> wrote:
>
> > On Wed, Jul 21, 2010 at 2:42 PM, Zach Tellman <ztell...@gmail.com> wrote:
> > > Both of those seem to be about persisting data across requests. I
> > > apologize if I'm being dense, but how does the threading model affect
> > > how they work?
>
> > They wrap the handler, that is they expect to see the request and the
> > response. That's not possible with Aleph since Aleph uses respond!, the
> > handler will return nil. Now that fn's can have metadata seems like this
> > could be worked around pretty easily.
>
> Okay, I see. Yes, if you try to decouple the request and response
> downstream from that middleware, it won't work. But if they're
> decoupled upstream (which is true of every code snippet in this
> thread), it should work fine. Clearly this is something that you have
> to pay attention to, but I don't think it's too taxing.
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
