On Tue, Mar 23, 2010 at 3:53 PM, Michael Snoyman <span dir="ltr"><<a href="mailto:michael@snoyman.com">michael@snoyman.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="gmail_quote"><div>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.</div>
</div></blockquote><div><br></div><div>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. </div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="gmail_quote"><div>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:</div>
</div></blockquote><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="gmail_quote"><div>* "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.</div>
</div></blockquote><div><br></div><div>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. </div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="gmail_quote"><div>* "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.</div>
</div></blockquote><div><br></div><div>I have dealt with this at all, so no idea.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="gmail_quote">
<div>* "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?</div>
</div></blockquote><div><br></div><div>Found?</div><div>I would just camel case all the names provided on this page:</div><div><br></div><div><a href="http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html">http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html</a></div>
<div><br></div><div>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</div><div><br></div><div>- jeremy</div><div>
</div></div>