Hi Conrad and Joey, On Tue, Feb 21, 2012 at 4:36 PM, Conrad Parker <con...@metadecks.org> wrote: > awesome! I've prepared some patches for network to add this module and > its tests, in this branch: > > https://github.com/kfish/network/tree/options > > I didn't modify any other modules, perhaps Network.Socket.Options > should be re-exported from Network.Socket, and perhaps > {get,set}SocketOption should be deprecated?
I think that makes sense. The API looks fine except: HasSocket - I don't think we want to abstract over sockets here, as we don't do so in the rest of the module. Seconds and Microseconds - These seem a bit misplaced here. I'd say so with Int. setHandleTimeout - If we want to keep it at all it should go in Network and not be conditionally exported. timeouts - we need to think about how this interacts with the I/O manager and provide a consistent API across platforms. I suggest we leave them out until we have done so. I've thought about doing this change before, but I didn't have time to fully explore the design space. I'm happy to accept these patches if someone does that for me. :) In particular: * Should we use an algebraic data type to represent options? I don't think so, for the reason pointed out in one of the source code comments in Joey's library. * Are we covering all possible options? Can there be custom options that can no longer be set by the user since we're enumerating a fixed set of options? * Are there any other design trade-offs? Someone needs to read the getsockopt and setsockopt man pages thoroughly and make sure we cover all the cases. * Are we covering all major OSes in the API? -- Johan _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe