Hi,<br><br><div class="gmail_quote">On Sat, Mar 3, 2012 at 10:38 AM, 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">
<div class="im">Hi, </div><div class="gmail_quote"><div><br>The tutorial I gave for CUFP 2011 was a multi-user web chat program using the Snap Framework. STM channels make this kind of problem super-easy to deal with. Don't be afraid of forking lots of Haskell threads for programs like this, because they're "green" threads, not OS threads (i.e. Haskell threads are M:N multiplexed onto OS threads) and as such they have very little overhead.<br>
</div></div><br>Maybe you'll find the code interesting: <a href="https://github.com/snapframework/cufp2011" target="_blank">https://github.com/snapframework/cufp2011</a>. The "business logic" of using STM channels is here: <a href="https://github.com/snapframework/cufp2011/blob/master/src/Snap/Chat/ChatRoom.hs" target="_blank">https://github.com/snapframework/cufp2011/blob/master/src/Snap/Chat/ChatRoom.hs</a></blockquote>
<div><br></div><div>That's exactly what I would have needed, several times in the past 2 years. I've been wondering about a good way to abstract this to have a library where you'd just plug your "business logic" and thus not have to care anymore about the implementation details, once and for all. I don't have the feeling stm-channelize is the best we can achieve. This really can be made simpler from the user's point of view.</div>
</div><div><br></div>-- <br>Alp Mestanogullari<br>