Hi,
On Wed, Feb 22, 2012 at 10:43 AM, Joey Adams
I know it's a bit ugly, but not having it makes it hard to work with unmanaged sockets (e.g. those buried under Handles). If the functions take a managed Socket, you'd have to say something like:
setRecvTimeout (MkSocket fd undefined undefined undefined undefined) 120000000
If they take CInt instead, users of the higher-level API would have to say:
setRecvTimeout (fdSocket sock) 120000000
But the network package doesn't try to let you work with raw file descriptors elsewhere (e.g. send and recv.) I'm not saying that functions on Fds aren't useful, they are, just that the network package is the wrong place for them. I'd put them in the unix package.
I use Int64 for Microseconds, to avoid truncation when Int is 32 bits. 2^31-1 microseconds is only 35 minutes and 47.483647 seconds. Perhaps I should just use Int and Int64, and be sure to document what units are used.
We should use whatever the underlying OS uses. If that's a 32-bit int, using a 64-bit int on the Haskell side doesn't help us. The goal here is to faithfully match the underlying APIs.
network-socket-options isn't comprehensive. It currently should have all of the SOL_SOCKET and IPPROTO_TCP options present in both Linux and Windows. It compiles on both. I haven't tested on Mac OS X or FreeBSD.
I think it'd be better to start with at least some options, and add more as users ask for them. One problem with adding every option we possibly can right now is that none of the options will get documented. If a user asks for a specific option and provides a reason for needing it, we can include this information in the documentation.
Starting small is fine, but we should think ahead so we don't paint ourselves into a corner. As long as it's possible to add other options in a natural way, it's fine. -- Johan