[Haskell-cafe] ANN: Webwire 0.1.0, netwire 1.2.5
lists.haskell at dbp.mm.st
Fri Sep 16 16:19:39 CEST 2011
I'm also excited to see examples. Even simple ones!
On Sep 16, 2011, at 5:24 AM, Ertugrul Soeylemez wrote:
> 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, 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)
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 881 bytes
Desc: This is a digitally signed message part
More information about the Haskell-Cafe