<div class="gmail_quote">On Mon, Jun 22, 2009 at 1:22 AM, Thomas DuBuisson <span dir="ltr">&lt;<a href="mailto:thomas.dubuisson@gmail.com">thomas.dubuisson@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

I&#39;m in favor of the entire Network library being reworked with an<br>
improved API that is higher level and type-safe instead of a direct<br>
translation/FFI of Berkeley sockets.   I also would like the Network<br>
package to export Data instances for headers while taking advantage of<br>
pretty, prettyclass, and parsec.  I started such work with<br>
network-data but never really got off the ground with it.<br>
<font color="#888888"></font></blockquote><div><br>I&#39;ve given this some thought. There are a few different things that would be nice to have in a new API:<br><br>* Use a binary type (e.g. ByteString) instead of Strings. (see network-bytestring)<br>

* Encoding more things in the type system, in particular the socket state (opened, closed, connected, etc). I would like to avoid a very heavyweight encoding though.<br>* Allow folds over the input i.e. foldSocket :: (a -&gt; ByteString -&gt; a) -&gt; a -&gt; Socket -&gt; IO a<br>

<br>I&#39;m all for having a higher level API but I would like to keep the Berkeley socket interface. The reason is the following: If we provide a higher level API that does not expose the whole underlying OS API there will be some users who can&#39;t use the library and will have to resort to writing their own bindings. I&#39;ve seen this problem in a few other libraries. The reasoning often goes something like this: This interface will cover 90% (or 95%) of all the use cases so its sufficient for most people. The problem with this kind of reasoning is that I have to write my own OS bindings for every ten libraries I use (on average).<br>

<br>Perhaps we should start a wiki page where we can take some notes on things that could be improved in the style of Haskell&#39; discussions (i.e. outlines of the problem together possible solutions together with their trade-offs. Python&#39;s PEPs are a good model here)?<br>

<br>-- Johan<br><br></div></div><br>