Potential Network SIG
johan.tibell at gmail.com
Tue Aug 25 04:10:41 EDT 2009
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>
>> 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
> 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.
More information about the Libraries