You received this message because you are subscribed to the Google Groups "Unfiltered" group.
To unsubscribe from this group and stop receiving emails from it, send an email to unfiltered-sca...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
On Wed, Jul 24, 2013 at 12:58 AM, chris <ch...@thegodcode.net> wrote:Hello list,I wanted to get some feedback on an experimental module for using unfiltered as a frontend for finagle: https://github.com/chrislewis/unfinagledWe're evaluating tools to aid in building transparent network services on both ends of our stack, and twitter's finagle is a pretty attractive option. However, processing http requests for a non-trivial client-facing web application a'la netty primitives can be cumbersome, to put it mildly. On the other hand, unfiltered is awesome for this, never mind existing knowledge and code we have in house. It's early stage so there may be issues, but it is extremely small. Please share any feedback, especially if you are currently using or evaluating finagle (I'm new).Very cool! Now I've seen unfiltered used both as a backend for scalatra and a front end for finagle. I've recently been embracing "the good parts" of the twitter scala ecosystem. This is a neat way of integrating with a core part of it. I'll definitely check this out. I would have called it "unfangled" :) Anyway, nice work.
I wanted to make scala Futures "first-class" by allowing creating an intent type Request => Future[ResopnseF]. I.e, I don't want to add the completions handlers and invoke respond() manually - all of our responses are futures. Does what I did with FinaglePlan at https://github.com/daggerrz/unfinagled/tree/feature/scala-futures/src/main/scala/net/godcode/unfinagled make sense for that?