[Original discussion in haskell-cafe: http://www.haskell.org/pipermail/haskell-cafe/2009-February/055270.html] Manlio Perillo:
Here are the problems:
1) supported HTTP methods are fixed, since you use a custom data type
(Btw. It is not my proposal, Johan Tibell has written it. I'll mail him to notify him about this discussion.) I agree with that. In my own framework prototype i have data HttpMethod = OPTIONS | GET | HEAD | POST | PUT | DELETE | TRACE | CONNECT | Extension String deriving (Eq, Show)
2) no support for other possible CGI variables (or simply custom variables: I use the environ dictionary to store application configuration, and I think it is a great thing).
A user dictionary / association list could be useful. A Trie is probably faster than a Map so i am not sure if the Map type should be used. Could also be implemented by the frameworks themselves.
3) No support for optimized file serving, like with WSGI file_wrapper
Would be nice to have provided it is cross-platform.
4) No support for keeping "complex" state (like database connection) in the environ.
I have read some examples with CGI package, where a custom monad transformer is used. I'm not sure if this solution is flexible and "scalable".
This should be a task for the framework itself. Using a ReaderT or StateT transformer is very common in Haskell.
5) I can't find documentation about the type of the response. It is rather clear that it is (ByteString, [(ByteString, ByteString)], Enumerator)
but this should be documented somewhere.
It's a wiki so feel free to change it or add more documentation. About the enumerator, using it is indeed debatable because it is not immediately obvious how it works, but i haven't seen anything for Haskell that works better. Like other haskellers have said lazy bytestrings with IO is asking for trouble. I have been bitten by it myself and it is hard to debug. Imho lazy bytestrings are only useful when the data generator is a pure function. Regards, Felix