<br><br><div class="gmail_quote">On Mon, Mar 15, 2010 at 10:04 PM, Gregory Collins <span dir="ltr"><<a href="mailto:greg@gregorycollins.net">greg@gregorycollins.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Michael Snoyman <<a href="mailto:michael@snoyman.com">michael@snoyman.com</a>> writes:<br>
<br>
> [F]irstly, I believe your premise is mistaken: we're not trying to<br>
<div class="im">> "standardize interfaces" for the most part; it's true that WAI was<br>
> such an approach, but that's not the focus of this thread.<br>
<br>
</div>If it's not the focus, it's a recurring theme, especially in the context<br>
of multiple active efforts in that direction and postings on the list<br>
like this:<br>
<br>
> The Haskell language itself was created to consolidate fragmented<br>
> market of different FP languages. Are we ready to follow our<br>
> 'ancestors' and in their spirit do the same when it comes to<br>
> web-framework(s)?<br>
<br>
OK, obviously we're all on the same "team" here, we're all drinking the<br>
same kool-aid and there should be plenty of things we can agree upon:<br>
Haskell's not tremendously popular, there are only so many decent<br>
Haskell hackers, it would be good for us to pool our efforts and work<br>
towards common purposes. And there IS a lot of interest in and support<br>
of the idea of standardizing a web application interface for haskell:<br>
I've seen lots of positive chatter and off the top of my head I can<br>
think of at least three on Hackage, yours, Hack, and CGI.<br>
<br>
CGI has a historical reason to exist (it understands the CGI protocol)<br>
but the other two are "just plumbing". Which is fine! Plumbing is<br>
great, life would be really horrible without it. But in our case, I<br>
don't think it's necessary right now: we don't have good toilets or<br>
sewers! The marginal utility of producing a WAI/Hack adapter for our<br>
toolkit at this point in time is basically zero: we're talking about<br>
spending time making it easier to interoperate with *applications that<br>
don't exist*. In fact, the only ones I can even think of at the moment<br>
are gitit, and MAYBE the Hackage server. Chicken/egg, right?<br>
<div class="im"><br></div></blockquote><div>I don't think it's really fair to put CGI in the same category, and the Hack/WAI issue is well documented: Hack is simple, WAI is performant. However, let me address the meat of your claim: even though you don't see the value, doesn't mean there is none. I'm able to write an application against the WAI and test it locally with the SimpleServer, then deploy it with CGI. That by itself justifies its existence for me.</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">
<br>
> you claim that anyone could write an adapter between two interfaces;<br>
> look at the code for hack-handler-hyena and you'll understand the<br>
> folly of that sentiment.<br>
<br>
</div>Are you kidding? It's 164 lines of not-that-hairy code, a full third of<br>
which is a status code lookup table. (OK, I'm going to try to be less<br>
argumentative :) )<br>
<div class="im"><br></div></blockquote><div>It wasn't the line count I was talking about: it requires spawning a separate thread to convert the Enumerator to a lazy bytestring. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">
<br>
> But more to the point: because of WAI, we don't *have* to write the<br>
> adapter,<br>
<br>
</div>This is the "M*N" VS "M+N" argument that the Rack guys make, which would<br>
be a perfectly good argument except that for us (pretty much)<br>
M=N=2. Keep in mind that WSGI (and to a lesser extent, this applies to<br>
rack) was created in the context of a bunch of webserver backends and<br>
more than half a dozen huge Python web toolkits, any one of which<br>
probably had more person-hours invested in it than all of our stuff put<br>
together.<br>
<div class="im"><br>
<br></div></blockquote><div>I don't really see your point here.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">
> and I don't see any substantive critiques of the WAI approach. (If<br>
> there are, we can address them by fixing the WAI.)<br>
<br>
</div>...and I just said I was going to try to be less argumentative.<br>
<br>
Your iteratee formulation is wrong, for starters. You picked the one the<br>
current Hyena is using, which Johan is currently in the process of<br>
abandoning because the other way is clearly better -- an explicit<br>
existential variable for the state is not as clean as the other<br>
formulation which pushes that goop down under the lambda, into a<br>
continuation. The Iteratee type from the iteratee library also has a<br>
convenient Monad instance (a big win!). I don't see that one is possible<br>
here, especially since there's no way that I can see for your iteratee<br>
to partially consume an input; how can you compose them?<br>
<br>
The Source thing is a little wacky, it should be an Enumerator<br>
instead. Again, the point of these things is that they *compose*;<br>
iteratees, which consume chunks of data, plug into enumerators, which<br>
produce them. So the request body should be an enumerator, and you<br>
process it by providing it an iteratee to read the data; the response<br>
body is an enumerator the user fills out, which plugs into an iteratee<br>
that splats it out the socket.<br>
<br></blockquote><div>So, instead of speaking rhetoric, can you give a concrete example where the Source is *bad*? It has serious benefits over Enumerator, such as the ability to convert (via unsafeInterleaveIO) into a lazy bytestring.</div>
<div><br></div><div>I'm happy to see a better approach, why not give me a datatype for the "obviously better" Enumerator?</div><div><br></div><div>(Hint: releasing no code and using phrases like "clearly better" are not going to win any arguments.)</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Speaking of which, you don't define an iteratee type, given your<br>
formulation it should be:<br>
<br>
type Iteratee a = a -> ByteString -> IO (Either a a)<br>
<br>
or more generally<br>
<br>
type IterateeM m a = a -> ByteString -> m (Either a a)<br>
<br>
which is exactly the Hyena definition.<br> </blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
The Status datatype is a mess. The requestHeader field should probably<br>
be a Map instead of an alist. RequestHeader and ResponseHeader don't<br>
need to have all of those header constructors in the datatype like that;<br>
as a result you have "ReqContentLength" which is awkward to say the<br>
least. Not to mention the fact that web application code should never<br>
have to get its hands dirty dealing with content-lengths for requests<br>
anyways; that should be handled on the enumerator level.<br>
<br></blockquote><div>That just shows a misunderstanding on your part: the content-lengths are *not* handled at the application level, though the information is available to the application. Why would I censor it? And would you care to elaborate on "Status datatype is a mess"?</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Let's say I use the generic "RequestHeader ByteString" constructor. HTTP<br>
header names are supposed to be case-insensitive, and your Eq instance<br>
does a case-sensitive comparison: 'RequestHeader "x-foo" /=<br>
RequestHeader "X-Foo"', which is wrong; now I can't use "lookup" to pick<br>
a header out of the alist.<br>
<br></blockquote><div>This is a valid concern. However, my goal in that decision is to keep things as close to the wire as possible. On the wire, x-foo and X-Foo are different. You also are conveniently ignoring all character encoding issues. True, HTTP has a character encoding defined, but do you trust ever web client in the world to respect all this?</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Request has an entry for remoteHost but not remotePort. Request contains<br>
no cookies, query parameters, or POST parameters; I'm supposed to parse<br>
them myself? Users of Java servlets are snickering.<br>
<br></blockquote><div>Yes, you are. You clearly have a misunderstanding about what WAI is about (or are just trying to attack baselessly): it's meant to represent the raw data.</div><div><br></div><div>(And if anyone wants remotePort for any reason, let me know. I have yet to see a need for it, and no one has asked.) </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
I'm really not trying to badger you here (honest), I'm being hyperbolic<br>
to make a point: for nearly all of the criticisms I just made, there's<br>
room for a legitimate disagreement about what is the "best" way to<br>
approach the solution; lots of people wouldn't want to use iteratees at<br>
all, for instance! I also wouldn't expect you to rearrange the whole<br>
thing to cater to my whims or anyone else's, either.<br>
<br>
I think that if we're going to standardize, one of the following<br>
preconditions has to hold:<br>
<br>
* the standard is superior on engineering merits, solves concrete<br>
problems/enables you to get work done, and is agreeable enough to<br>
enough people that it picks up community momentum by wide<br>
consensus.<br>
<br>
* the standard is imposed by fiat, maybe because it comes from the<br>
language vendor.<br>
<br>
* the standard comes out of a standardization committee effort which<br>
hammers out disagreements over a period of time to produce something<br>
which everyone can stomach --- I'd actually be pretty okay with this<br>
if it happened, but there's a reason "design by committee" is a<br>
perjorative.<br>
<br>
* the standard comes about as a result of market forces, i.e. blub<br>
toolkit becomes really popular and a standard emerges because<br>
everyone wants to interoperate with blub.<br>
<br>
Honestly, I just don't any of these things happening, not right now.<br>
<div class="im"><br>
<br></div></blockquote><div>Don't worry, I won't ask you to join the standardization committee ;).</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">
> Now, let me try to understand your point here: we need standardized<br>
> interfaces for applications to communicate with each other, but we<br>
> can't do that until we have the low level interfaces hammered out.<br>
<br>
</div>No, you're misrepresenting me here. What I said is that "we need<br>
pluggable applications that understand how talk to each other", NOT that<br>
those interfaces should be subject to standardization. There's a<br>
critical distinction there; you don't expect Django components to plug<br>
into a Zope app.<br>
<div class="im"><br>
<br>
> On the other hand, you say that it's premature to try to standardize<br>
> interfaces. And then you make it clear that the use case of many<br>
> people (shared hosting) doesn't interest you at all; based on previous<br>
> conversations, I believe this means that Snap will have *no* (Fast)CGI<br>
> support.<br>
<br>
</div>I wouldn't say that's necessarily true in the long term, although it's<br>
probably true that I myself am not likely to write it. FastCGI support<br>
is definitely not important to me, but if someone wanted it badly enough<br>
there's nothing in Snap (as of this moment) which would preclude her<br>
from writing whichever backend she wanted: CGI, WAI, Hack,<br>
whatever. That said, I'd be 100% a-ok with sacrificing CGI support<br>
specifically, because spawning a fresh process every time you want to<br>
service a request is, frankly, dumb and absurdly limiting. It isn't 1996<br>
anymore.<br>
<div class="im"><br>
<br>
> I think (correct me if I'm wrong) that everyone else here is in<br>
> agreement that the goal should not be to create a great framework that<br>
> will solve everyone's needs.<br>
<br>
</div>I do agree with this; my point all long has been that no one web library<br>
is going to satisfy everyone any more than one parsing combinator<br>
library or one regular expression library or one database could. I'm<br>
aiming to help create a great framework that satisfies my needs, and if<br>
it works for other people too: great.<br>
<div class="im"><br>
<br>
> The goal should be to create great libraries that can be used<br>
> independently.<br>
<br>
</div>..but not necessarily this, at least not in the broader context of<br>
"people writing web applications". Obviously I agree in general terms:<br>
self-contained, single-purpose libraries are great. There's no reason to<br>
have a bunch of competing libraries to parse and output RSS, for<br>
instance.<br>
<br>
A productive *web framework*, on the other hand, by its nature makes a<br>
whole set of "convention over configuration" assumptions about how<br>
requests are handled and routed, how data is accessed, how users are<br>
managed, how to hook into an admin panel, how templates are laid out on<br>
disk, which template system to ship out of the box, how components are<br>
specified, how they talk to each other etc etc etc. I see the future<br>
being a lot like the present, where a heterogeneous collection of<br>
frameworks of varying comprehensiveness and quality provide their own<br>
self-contained ecosystems.<br><br></blockquote><div><br></div><div>Michael </div></div>