ANN: Happstack 7

[Jeremy Shaw]

We are pleased to announce the  release of Happstack 7!

Happstack is a fast, modern, web application framework written in Haskell. Please check out the brand new happstack.com website to read about what is new in Happstack 7, and what we are planning for Happstack 8, and what makes Happstack great!

http://www.happstack.com/

- jeremy

[Lennart Kolmodin]

Congratulations to the new release, and may I say that the homepage looks smashing! :D

With the work of Antoine Latter's happstack-wai (https://github.com/aslatter/happstack-wai), it's likely possible to serve happstack applications through my (still in development) SPDY WAI server (https://github.com/kolmodin/spdy) although I have not tested this combination yet.

Before I saw happstack-wai I had a quick look at the happstack API and saw that the Request keeps the request body as a (lazy?) String. I'm curious to the rationale for this, as one could expect a lazy bytestring would be more efficient, and some kind of stream would better support error handling (given that the String is indeed lazy). Sorry if this has been discussed before, I searched the mailing list without finding anything.

Feels like Happstack has been reborn, thanks again!

Cheers,

  Lennart

[dag.od...@gmail.com]

On 30 March 2012 11:36, Lennart Kolmodin <kolm...@gmail.com> wrote:

Before I saw happstack-wai I had a quick look at the happstack API and saw that the Request keeps the request body as a (lazy?) String. I'm curious to the rationale for this, as one could expect a lazy bytestring would be more efficient, and some kind of stream would better support error handling (given that the String is indeed lazy).

The rationale is probably that Happstack has been around for years. :)

Part of the Happstack 8 roadmap is a new HTTP backend, likely using Pipes, possibly with support for SPDY, and including a new Request datatype and quite probably much fewer uses of String.

[Jeremy Shaw]

On Fri, Mar 30, 2012 at 4:36 AM, Lennart Kolmodin <kolm...@gmail.com> wrote:

 

Congratulations to the new release, and may I say that the homepage looks smashing! :D

Thanks!

 

Before I saw happstack-wai I had a quick look at the happstack API and saw that the Request keeps the request body as a (lazy?) String.

Hmm. I am not sure what you are referring to. 

Looking a the Request type:

http://www.happstack.com/docs/happstack-server-7.0.0/doc/html/happstack-server/Happstack-Server-Types.html#t:Request

we see that the rqBody as the type:

    rqBody :: MVar RqBody

and RqBody is defined as:

newtype RqBody = Body { unBody :: L.ByteString } deriving (Read,Show,Typeable)

So, it is, as you would expect, a lazy ByteString. RqData is defined as a ByteString in HAppS as well.. so it is always been that way in Happstack. 

The MVar is there so that you can process the request body as it streams over the network and have it garbage collected as you go. For example, when saving a file upload to disk, the whole file does not get sucked into RAM.

There are other places in happstack-server where we use String instead of ByteString or Text. That is mostly because happstack was started back in 2004. So, I am pretty sure it predates the existence of ByteString, and it is definitely older than Text. 

Most places that should be a ByteString have been updated. Not all places that could be Text are yet. We will see more modernization in that area in Happstack 8. 

- jeremy

[Lennart Kolmodin]

On Mar 30, 5:58 pm, Jeremy Shaw <jer...@n-heptane.com> wrote:

> On Fri, Mar 30, 2012 at 4:36 AM, Lennart Kolmodin <kolmo...@gmail.com>wrote:
>
> > Congratulations to the new release, and may I say that the homepage looks
> > smashing! :D
>
> Thanks!
>
> > Before I saw happstack-wai I had a quick look at the happstack API and saw
> > that the Request keeps the request body as a (lazy?) String.
>
> Hmm. I am not sure what you are referring to.
>
> Looking a the Request type:
>

> http://www.happstack.com/docs/happstack-server-7.0.0/doc/html/happsta...

>
> we see that the rqBody as the type:
>
>     rqBody :: MVar RqBody
>
> and RqBody is defined as:
>
> newtype RqBody = Body { unBody :: L.ByteString } deriving
> (Read,Show,Typeable)

Ah, yes, indeed. I don't know any more what code I looked at when I
wrote that, and I can't find anything similar.

> So, it is, as you would expect, a lazy ByteString. RqData is defined as a
> ByteString in HAppS as well.. so it is always been that way in Happstack.
>
> The MVar is there so that you can process the request body as it streams
> over the network and have it garbage collected as you go. For example, when
> saving a file upload to disk, the whole file does not get sucked into RAM.

This is what I was getting at. I see there is a part of the framework
to handle this, no needs for me to worry :)
http://www.happstack.com/docs/crashcourse/RqData.html#rqdata

> There are other places in happstack-server where we use String instead of
> ByteString or Text. That is mostly because happstack was started back in
> 2004. So, I am pretty sure it predates the existence of ByteString, and it
> is definitely older than Text.
>
> Most places that should be a ByteString have been updated. Not all places
> that could be Text are yet. We will see more modernization in that area in
> Happstack 8.

Sounds great!
>
> - jeremy