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
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
