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

[Jeremy Shaw]

On Tue, Mar 23, 2010 at 3:53 PM, Michael Snoyman <michael at snoyman.com>wrote:

> 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.
>

Right. I figured the only way it was going to actually get good is if people
were using it :) Some people have suggested it is not the right thing and we
should wait until we have more experience before creating something like
WAI. But I figure WAI is a good start, and trying to actually use it is what
will uncover the problems. My only complaint would be if it *was* set in
stone to early.


> 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:
>


> * "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.
>

It does feel a bit weird that some headers will have constructors, and other
won't. Uniformity feels pretty. Unfortunately, there is no way to extend
data types in 3rd party libraries. But we could add  functions that add new
headers in other libraries. For example, if you look at FilterT in
happstack-wai, it has a bunch of functions for the different status codes.
If a user wants to add additional functions in their own library, they can
-- and they will feel just like the built-in functions. No idea if something
similar would make sense for wai and the http headers.


> * "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.
>

I have dealt with this at all, so no idea.

* "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?
>

Found?
I would just camel case all the names provided on this page:

http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html

Though, I don't really care all that much, because the code for FilterT has
already been written, so I'll never have to see the constructors again :p

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