One of the areas that I am very interested in is agents and I have been doing quite a lot of work in this area lately. Agents can be used for a multitude of different purposes ranging from: isolated message passing, object caching, finite state machines, web crawling, and even reactive user interfaces. One of the ideas that I have been looking into lately is agent based scheduling.

The Frank application signature is currently undergoing a change from 'Request -> Async<'Response> to 'Request -> 'Response, where the 'Response includes a Body type that is: type Body = | Bytes of byte[] | AsyncBytes of byte[] Async | Segment of byte ArraySegment | AsyncSegment of byte ArraySegment Async | Str of string | AsyncStr [...]

Lately I’ve been taking a look at how you might write web apps with F# using various existing frameworks. Often these frameworks don’t quite work the way you want them to and have small but annoying nuances when using them from F#. These projects are: PicoMvc – a minimalist MVC like framework. The basic aim of PicoMvc is to make it really easy to map an incoming URL to an F# controller function and then choose a view engine to render the result of this function. (github/nuget) Log4f – an F# wrapper for [...]

I’ve been working on the Frank syntax lately. Following some help from @talljoe, Frank maps paths from a resource level rather than each HTTP method. Frank can then take advantage of combinators that add HEAD and OPTIONS based on the HTTP methods explicitly supported by the developer… something missing from most web frameworks, the notable [...]

When writing reactive applications using F# asynchronous workflows, it is important to run some operations on the right thread. User interface elements are accessible only on GUI threads and CPU-intensive computations should be done on a background thread. This article describes an extension of F# asynchronous workflows that guarantees correct use of threads using types.