Thanks for voting. Option #1 was our winner!

These results look like polls in American politics.

Example using Iteratee via IterIO, which claims to be a simpler model, complete with HTTP support.

Looking at this and Snap Framework, I see that an Iteratee is essentially a single-threaded event loop model for I/O fold monad driven by an enumerator (value producer). Notes appear to indicate that truly lazy (async) models can leak resources as the resource isn't always appropriately closed, as Anton noted above.

I thought Tomas\' AsyncSeq fit this description. I have yet to use Lazy types outside of MEF, but it appears to make sense. You appear to be lazily constructing the response, if I\'m reading that correctly. I had thought AsyncSeq would fulfill the desire to not block when sending data back across the socket, but I now see that such a view is reversed to reality.

I like the points you make. I initially enjoyed the freedom monads provide of not having to pass along a common object, but I do it all the time in C# and don\'t think twice. You are correct that it provides a more approachable api for those unfamiliar with monads. It also resolves the cases where a MonadTransform would be required, which is not available in F#.

Fwiw, I\'ve updated the FSharp.Monad project to use the unwrapped versions so that the developer can choose his/her own approach.

While on Stream, the reason we didn\'t go with that in OWIN was due to the bulkiness of the abstract class. I noticed in your gist that you used an ArraySegment<byte>. Was that intended to represent the entire stream or just an element?

@mausch I\'m glad you have that perspective. I noticed that in your Reader use, noted by Anton. I added the wrapper types to FSharp.Monad based on Matt Podwysocki\'s blog series, among others. I am inspired to remove them (as I did originally).

That\'s an excellent point. The current stuff comes from working with some of the OWIN guys previously, where I started getting caught up with byte[] and ArraySegment<byte>. I initially started with Stream and then TextReader and TextWriter. I hadn\'t made my way back to Stream, but it\'s probably time. Thanks for the nudge. :)

Among other things. :) I need to probably add additional types, including `obj`, but I thought bytes were best to start. Xml and Json can be represented as strings, and with the desire for conneg, I don't really want to allow direct serialization into a specific format. I might bend on that.

Given that all adapters will implement the extensions to modify what the app functions actually do, it should be easy to write a function that takes some input object and returns an output object, applying the extensions to mold and shape the inputs and outputs to the source system's requirements. In other frameworks, this is done "magically"; here, I want to explicitly apply the transformation functions.

You are quite right. However, while I'm providing support for OWIN, I'd like to provide the familiarity of other enviroments. I quite like the HttpRequestMessage/HttpResponseMessage objects used by WCF. I thought about building something similar or even using those for my implementation, but others prefer the HttpContext(Base) approach or the OWIN abstractions. All are welcome... or so I hope to make happen. :)