Also, I've just created a mailing list for Aleph at http://groups.google.com/group/aleph-lib, since it seems like that might reduce the clutter here.
On Jul 21, 10:40 am, Zach Tellman <ztell...@gmail.com> wrote: > 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
