<div dir="ltr"><br><br><div class="gmail_quote">On Mon, May 24, 2010 at 6:55 PM, Gour <span dir="ltr"><<a href="mailto:gour@gour-nitai.com">gour@gour-nitai.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
On Mon, 24 May 2010 17:47:53 +0300<br>
<div class="im">>>>>>> "Michael" == <<a href="mailto:michael@snoyman.com">michael@snoyman.com</a>> wrote:<br>
<br>
</div>[snip]</blockquote><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Michael> I did some work after the Snap release to actually get Yesod<br>
Michael> running on top of Snap. Gregory has been very helpful, and<br>
Michael> will hopefully be releasing a newer version of snap-server<br>
Michael> that provides the functionality I'm missing. (Basically, Snap<br>
Michael> processes url-encoded form data, while WAI specifies that the<br>
Michael> POST body be passed to the application.)<br>
<br>
Would it be better option for shared-hosting scenario and FCGI<br>
serving?<br>
<br></blockquote><div>Snap is definitely *not* geared at shared hosting. I discussed this with Gregory a while ago, and unless he's changed his mind since, they're not interested in anything but dedicated hosting. So I would definitely say stick with FastCGI (or CGI... I'm working on some benchmarks right now).</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Michael> * Yesod uses the WAI definition of enumerator while Snap uses<br>
Michael> the iteratee package. The former is much simpler, the latter<br>
Michael> more powerful. I'd be very interested in a performance<br>
Michael> comparison of the two, my instinct tells me the former wins.<br>
<br>
I haven't been able to grok either of them...all I can say is that I<br>
understand this is hot topic in Haskell, and if one wants to dive into<br>
web development with Haskell, there is need to understand them more<br>
(hopefully not fully).<br>
<br></blockquote><div>Well, Yesod at least shields you from dealing with enumerators, and I believe most other high-level frameworks will do the same.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
[snip]<br></blockquote><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Michael> * Yesod has type-safe URLs, I don't believe Snap has any<br>
Michael> similar feature.<br>
<br>
Hmm, this is an important issue and one of the selling tickets to use<br>
Haskell instead of e.g. Python/Django (which we recently abandoned).<br>
<br></blockquote><div>I know that since implementing this feature in Yesod it's completely changed the way I write web apps. There's no more fear of changing my URL structure: I just do it, and the compiler tells me if I need to fix anything. If Yesod goes in the advertising direction, this will most likely be the top item on the list.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Michael> * Some design decisions, notably they use a mutable states for<br>
Michael> modifying request and response values while Yesod uses a<br>
Michael> Reader for the request, and writer for response headers and<br>
Michael> actually returns a value for the response body/content type.<br>
<br>
What are some of the implications of the above design difference?<br>
<br></blockquote><div>I personally prefer the Yesod approach, but of course I'm a biased source. I found writing code against Snap to be a little... unnatural. For example, you have to call modifyResponse and give it a function that applies changes to a response already in existence. It feels very object-oriented to me in fact.</div>
<div><br></div><div>In Yesod, you can get access to the request via getRequest, and then return a value that can be converted to a response. The monad plays a much less important role, and feels overall more functional.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Michael> I'm sure there are many more differences, but the main point<br>
Michael> is this: these two projects are very different types of<br>
Michael> frameworks. And I hope and expect that the two projects will<br>
Michael> have some cross-polinization going forward (in fact, we<br>
Michael> already have).<br>
<br>
Thank you for the input. It looks that it would be nice to make<br>
another comparison when (hopefully) Snap gets some more higher-level<br>
stuff and when Yesod will have some solution for persistence<br>
(hopefully with the ability to use RDBMS).<br>
<div><div></div><div class="h5"><br>
<br></div></div></blockquote><div>Given my current line of employment, RDBMS is my top priority for the persistence layer. My thought right now is to start with MySQL, since it has the weakest Haskell support at the moment. Ideas are percolating, but I haven't had a chance to actually write something concrete yet.</div>
<div><br></div><div>Michael</div></div></div>