<div class="gmail_quote">On Fri, Aug 21, 2009 at 9:49 PM, Thomas DuBuisson <span dir="ltr"><<a href="mailto:thomas.dubuisson@gmail.com">thomas.dubuisson@gmail.com</a>></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;">
<br>
Johan suggested starting a SIG to hammer out a design for a new<br>
Network API seeing as the current API, a straight-forward Berkeley<br>
binding, doesn't seem to please anyone in a Haskell context.</blockquote><div><br>Thanks for getting the conversation started!<br><br>Your agenda is very ambitious, which worries me a little. As a "how to get things moving" tip, I'd very strongly suggest trying to make progress on the lowest level bindings first, as they will be the most concrete, and the least likely to provoke prolonged discussion and disagreement.<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
2) Maintain type safety by using type classes for most things.<br>
<br>
Unlike Network.Fancy and Network.Socket (which have IPv4 and IPv6 as<br>
constructors of the same data type), I think we should allow for the<br>
possibility that some users of the library will be limited to just one<br>
IP version without resorting to partial functions. I suggest type<br>
classes to cover this aspect (class Address, class Port, etc).<br>
</blockquote><div><br>I don't understand what this might mean. Code examples or type signatures are going to be much easier to follow than English descriptions.<br> <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
3) Use Bytestrings (and have corrosponding .Lazy modules) for efficiency.<br>
</blockquote><div><br>That's already a step up from the lowest-level bindings, which should be using Ptr a.<br> <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
4) Support more features<br>
Features such as Multicast, Header inclusion (IP_HDRINCL), address<br>
binding, etc. IOW, most the IP_ and SO_ options of socket (7) and ip<br>
(7) man pages. It would be rather nice if we were able to expose<br>
these in a friendly way - but with our cross platform concerns that<br>
might not be a good idea (e.g. I'm not familiar with windows).<br>
</blockquote><div><br>Providing Network.Windows and Network.Linux and Network.BSD etc modules would work fine for non-portable platform-specific features (of which there are many).<br><br>As for providing instances for the likes of Binary, there are good reasons not to do that in the core network package, because it will drag in dependencies on quite a few third-party packages that are either not in core (binary) or have questions over their futures (Parsec).<br>
</div></div>