Potential Network SIG

[Johan Tibell]

On Mon, Aug 24, 2009 at 11:22 PM, Bryan O'Sullivan<bos at serpentine.com> wrote:
> On Mon, Aug 24, 2009 at 12:48 PM, Johan Tibell <johan.tibell at gmail.com>
> 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