Re: Potential Network SIG

On Mon, Aug 24, 2009 at 11:22 PM, Bryan O'Sullivan wrote:

On Mon, Aug 24, 2009 at 12:48 PM, Johan Tibell wrote:

...

My plan for network-bytestring has always been to offer a Network.Socket.Buffer with function such as 'recvInto' that work on buffers. The higher level bytestring interface can then be implemented in terms of this interface.

How would a Buffer differ from a combination of Ptr a and CSize? (My implied argument is that it shouldn't.)

It wouldn't. A raw Ptr a and a size (but possibly not CSize?) was what I had in mind. recvInto :: Socket -> Ptr a -> CSize -> IO () (Or perhaps just call it 'recv' since it would live in a separate module.)

...

I've been struggling a bit with how to expose less frequently used functionality in the BSD socket API such as the 'flags' parameter to 'send'. It feels a bit unfortunate to have to pass a "no flags" value in the most frequent case. Optional keyword parameters would be useful here.

send vs sendWithFlags would be workable, since we're not going to get keyword or optional arguments in a happy-making form in the language any time soon. Of course, just making people use defaultFlags (as getAddrInfo does) isn't too awful, either.

sendWithFlags might be the best solution given what we have to work with. It would give us twice as many functions in the send/recv/sendTo/recvFrom part of the API which is unfortunate. If there were more than one optional parameter I would, as you mentioned, go with a record type for the options as it's more extensible (i.e. doesn't break user code as long as the user only uses the accessors) and doesn't increase the number of functions. -- Johan