[Haskell-cafe] Re: ANNOUNCE: happstack 0.5.0

[Jeremy Shaw]

On May 5, 2010, at 8:01 AM, Michael Snoyman wrote:
>
> alas, there is no happstack-wai specific demo at the moment. But, if  
> there was, it would look a lot like a normal happstack-server app...
>
> It wouldn't look like a normal WAI app? If you want something like  
> that, Simon Hengel wrote a nice Hello World for WAI; it's available  
> in the github repo[1].
>

Actually, I am wrong, I did have a little demo app:

http://www.patch-tag.com/r/mae/happstack/snapshot/current/content/pretty/happstack-wai/Main.hs

It looks exactly like a normal happstack app, and offers no clues that  
it is WAI based.

main :: IO ()
main = simpleHTTP 8000 $
        msum [ dir "foo" $ ok $ toResponse "foo" -- handles /foo
             , dir "bar" $ ok $ toResponse "bar" -- handles /bar
             , do nullDir                        -- handles /
                  ok $ toResponse "hello"
             , notFound $ toResponse "Invalid URL" -- handles anything  
else
             ]

In this demo, the routing & dispatching is handled by the filter  
combinators such as 'dir' and 'nullDir' (there are also ones like  
'path' which can be used for path components which represent  
'variable' components such as integers). The combinators are based  
around MonadPlus -- hence the use of msum to combine them. They are  
tried in the order presented until one matches completely and returns  
a 'Response'. Of course, we could use web-routes instead.

the functions like, 'ok' and 'notFound' take care of setting the  
response code.

The 'toResponse' function takes care of converting the values (in this  
case strings) to a 'Response', and setting the Content-type.

There are other features not shown here, such as looking up values  
submitted as POST data , via the query string, or as cookies. There is  
also stuff for dealing with exceptions, escaping early and returning a  
Response, ways to apply filters (such as gzip compression), ways to  
add on-the-fly validation (of html or other content types), and more!

It is this high-level interface that makes happstack-server  
interesting. Hence the interest in using WAI for the 'backend' stuff  
that isn't really all that visible in the first place.


> As far as performance goes, I can't imagine you'd see any  
> significant difference without an enumerator-biased test, but I  
> could be wrong. If you want to try something, I'd suggest outputting  
> the contents of a file (obviously without the sendfile syscall). If  
> you want help writing a WAI version, let me know, I'd be interested  
> in the results of a comparison.

As for 'performance', there is the raw speed. But also issues like  
stability and reliability. And bugs. Or fixes for real-world usage.  
For example, implementing cookie handling by the spec does not quite  
work. There are some workarounds needed to handle cookies issued by  
google. And webkit and chrome browsers have issues with double quotes  
around the domain. Of course, these are also the reasons, ultimately,  
to use WAI. Instead of everyone having to learn that cookies are  
broken, and fix them in every framework, we can just do the hacks  
once, and everyone wins.

- jeremy