[Haskell-cafe] ANN: Webwire 0.1.0, netwire 1.2.5

Ertugrul Soeylemez es at ertes.de
Fri Sep 16 11:24:40 CEST 2011

Michael Snoyman <michael at snoyman.com> wrote:

> I'm not sure what you mean by runtime-only, could you clarify?

The session is inherently bound to its current continuation, and the
continuation is a function, i.e. cannot be serialized.  This is a
generalization, which comes with the price that sessions are lost, as
soon as you quit the program.

In other words:  Applications desiring to save the state need to capture
it as something serializable to be able to restore sessions (at least
partly) later on.

> The reason I'm wary of continuation-based frameworks is that (at least
> from what I've seen) they are purposely non-RESTful. I know REST is a
> buzzword, but the other way to put it is: you're going to end up
> working against most of what HTTP is doing. There are good reasons why
> HTTP is stateless, and that shouldn't be circumvented lightly.

Yes, this is indeed a problem with the traditional explicit continuation
approach.  However, webwire solves this problem mostly, because
continuations are implicit and bound to the current resource.  You will
see the effect of continuations mostly in global or resource-specific
stuff like authentication, forms, sessions, etc.

In other words:  What FRP buys you here is that you can write your
applications in a dialog style.  Resource URIs need to be managed by the
application developer and are not in any way dealt with by webwire.

> I don't want to go too far on this right now, as I'm not an expert on
> cont-based frameworks, and I'm certainly not sure how webwire works.
> But from what I've seen in the past, you end up with ugly URLs and bad
> caching behavior. I think web developers *should* have to think about
> the fact that a page request is an inherently stateless operations,
> and storing state data should be a huge exception[1], not the norm.

As noted above, the URI problem is not an issue in webwire.  And as for
the caching, one really great thing about the FRP approach is that you
can actually infer the change rate of a resource to some extent.


nightmare = unsafePerformIO (getWrongWife >>= sex)

More information about the Haskell-Cafe mailing list