I don't really understand what's being debated here. Aleph is fully Ring-compliant in every way but its threading model. I don't think anything in the Ring utilities are thread-aware, so they're all okay to use. I'm not very familiar with Compojure, but as long as you're willing to make an explicit decision as to where its handler function is executed, I'd imagine it would work fine as well. It doesn't make sense to create an "adapter" that uses a specific threading model all the time; the fact that you have a choice is what makes Aleph different from ring-netty-adapter.
Also, please try to remember that Aleph was originally written to raise the question of how to write asynchronous network applications in Clojure, not to answer it. I'm working on some ideas in a separate branch that I think are a pretty good approach, but I fully expect there will be further discussions and changes once that's done. Zach On Jul 21, 8:15 am, Marko Kocić <marko.ko...@gmail.com> wrote: > On Jul 21, 4:38 pm, Janico Greifenberg <j...@acm.org> wrote: > > > On Wed, Jul 21, 2010 at 4:11 PM, Marko Kocić <marko.ko...@gmail.com> wrote: > > > Something like ring-aleph-adapter, however trivial it might be to > > > implement, will help in seamlessly switching existing applications to > > > aleph/netty. > > > But why would that be useful? Maybe I'm missing something here, but I > > thought the idea behind aleph was to experiment with an asynchronous > > API. To get full ring compatibility, you would need to synchronize the > > response again. > > Ring API seems to me minimalistic enough that everything could be made > to conform to it without sacrificing any functionality. > > Having aleph-adapter would be useful in two ways. One is that it would > be > possible to use all of the ring goodies and addons like compojure > routes > and stuff out of the box, while keeping being semi asynchronous. > > While ring-netty-adapter and ring-jetty-adapter are blocking the > thread > during the whole execution of handler function, while the adapter will > allow > to do processing async and only require io! in the end, when actual > result > is returned. Something similar to previous example someone already > posted like: > > (defn aleph-to-ring-handler [req] > (respond! req (ring-handler req))) > > ring-handler could take a long time to compute, but thread will not be > blocked until it is finished. > > Of course, I would also like to see how it could be changed (api-wise) > to > allow sending chunks of data to the response stream when needed, and > not > only in the end of the handler. > > Api for aleph and ring could look the same, while the only difference > wold be > async versus sync behaviour. > > > If you want to use netty instead of jetty or tomcat etc., you could > > try the ring-netty-adapter > > (http://github.com/datskos/ring-netty-adapter). > > I haven't looked at the details yet, but it seems (at a glance) like a > blocking > adapter? > > > > > --http://jgre.org -- 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
