[web-devel] Re: ANN: Salvia-1.0.0

[Michael Snoyman]

On Tue, Mar 23, 2010 at 10:00 AM, Jeremy Shaw <jeremy at n-heptane.com> wrote:

>
> I am not thrilled about certain aspects of Wai. For example, the Status
> type names the constructors after their numeric value instead of their more
> human friendly names. But at the same time, happstack users are not really
> going to know the difference. If you look at:
>
>
> http://patch-tag.com/r/mae/happstack/snapshot/current/content/pretty/happstack-wai/Happstack/Server/Filters.hs
>
> you will see that happstack provides it's own combinators for handling the
> response code -- so the end user won't even see a difference between the
> normal happstack server and the  wai based one.
>
>
I would just like to make two comments on this. Firstly, I think layering a
library on top of WAI is a perfect method for interacting with it the way
you want to. Secondly, WAI is not yet entrenched enough to be "set in
stone," and there are most definitely design decisions which are
sub-optimal.

If anyone is interested in changing the interface for WAI, I suggest they
bring up the ideas sooner rather than later. I can think of a few issues
that have been broached so far:

* "I don't like enumerators." Well, that one is going to be sticking around,
sorry. It's the whole impetus for WAI. If you want lazy bytestrings, use
Hack, it's a great package. Or even better: just layer your lazy bytestrings
on top of WAI; the reason the request body is a Source instead of an
Enumerator is so that it can be easily converted to a lazy bytestring.

* "It's using the wrong type of enumerators." I don't think it makes sense
at this point to add an iteratee dependency, since it appears that package
is young and unstable. If someone wants to suggest a different definition
for the Enumerator type *and explain why it's better,* I'm all ears.

* "Request and response headers should not have their own data types." I'm
open to discussion on this issue, though it's very pertinent to the next
point.

* "Request and response headers should have case-insensitive match for the
Eq instance." I'm thinking that this is the correct approach to take, and
would like input on it. (Thanks Gregory.

* "Status200 -> StatusOK." Once again, I have no strong feelings on this,
but I thought it was less debatable to use numeric codes than to pick a
name. For example, can anyone agree on what we should call code 302?

I'll make sure that WAI follows the PVP, so making these changes should not
affect code in use.

Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/web-devel/attachments/20100323/ad2f49af/attachment.html