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]

Post by 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

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

[d***@public.gmane.org]

Post by Lennart Kolmodin
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]

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

Thanks!

Post by Lennart Kolmodin
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]

Post by Jeremy Shaw

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

Thanks!

Post by Lennart Kolmodin
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.
http://www.happstack.com/docs/happstack-server-7.0.0/doc/html/happsta...
    rqBody :: MVar RqBody
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.

Post by Jeremy Shaw
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

Post by Jeremy Shaw
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!

Post by Jeremy Shaw
- jeremy