<br><br><div class="gmail_quote">On Tue, Mar 23, 2010 at 10:00 AM, Jeremy Shaw <span dir="ltr">&lt;<a href="mailto:jeremy@n-heptane.com">jeremy@n-heptane.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br></div><div class="gmail_quote"><div>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:</div>

<div><br></div><div><a href="http://patch-tag.com/r/mae/happstack/snapshot/current/content/pretty/happstack-wai/Happstack/Server/Filters.hs" target="_blank">http://patch-tag.com/r/mae/happstack/snapshot/current/content/pretty/happstack-wai/Happstack/Server/Filters.hs</a></div>

<div><br></div><div>you will see that happstack provides it&#39;s own combinators for handling the response code -- so the end user won&#39;t even see a difference between the normal happstack server and the ¬†wai based one.</div>

<div><br></div></div></blockquote><div><br></div><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 &quot;set in stone,&quot; and there are most definitely design decisions which are sub-optimal.</div>
<div><br></div><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><br></div><div>
* &quot;I don&#39;t like enumerators.&quot; Well, that one is going to be sticking around, sorry. It&#39;s the whole impetus for WAI. If you want lazy bytestrings, use Hack, it&#39;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.</div>
<div><br></div><div>* &quot;It&#39;s using the wrong type of enumerators.&quot; I don&#39;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&#39;s better,* I&#39;m all ears.</div>
<div><br></div><div>* &quot;Request and response headers should not have their own data types.&quot; I&#39;m open to discussion on this issue, though it&#39;s very pertinent to the next point.</div><div><br></div><div>* &quot;Request and response headers should have case-insensitive match for the Eq instance.&quot; I&#39;m thinking that this is the correct approach to take, and would like input on it. (Thanks Gregory.</div>
<div><br></div><div>* &quot;Status200 -&gt; StatusOK.&quot; 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><br></div><div>I&#39;ll make sure that WAI follows the PVP, so making these changes should not affect code in use.</div><div><br></div><div>Michael</div></div>