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

[Daniel Patterson]

I'm also excited to see examples. Even simple ones!

Based on my understanding of FRP (which may have little bearing on what webwire actually does, just what I hope it does), what makes it really different is that it is relatively stateless itself - that's kind of the point, that you model your system as a bunch of data sources, and you can change them with pure functions, and when you do that they will be updated anywhere you are using them without any explicit imperative stuff. I'm not sure how that translates to a server-side applications (the only web examples I know of have been javascript-based), or webwire itself so I'm curious to see how this works.

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[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.
> 
> 
> Greets,
> Ertugrul
> 
> 
> -- 
> nightmare = unsafePerformIO (getWrongWife >>= sex)
> http://ertes.de/
> 
> 
> 
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 881 bytes
Desc: This is a digitally signed message part
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20110916/9bcb35b8/attachment.pgp>