Potential Network SIG

[Johan Tibell]

On Mon, Aug 24, 2009 at 8:00 PM, Bryan O'Sullivan<bos at serpentine.com> wrote:
> On Fri, Aug 21, 2009 at 9:49 PM, Thomas DuBuisson
> <thomas.dubuisson at gmail.com> wrote:
>> 3) Use Bytestrings (and have corrosponding .Lazy modules) for efficiency.
>
> That's already a step up from the lowest-level bindings, which should be
> using Ptr a.

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.

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.

>> 4) Support more features
>> Features such as Multicast, Header inclusion (IP_HDRINCL), address
>> binding, etc.  IOW, most the IP_ and SO_ options of socket (7) and ip
>> (7) man pages.  It would be rather nice if we were able to expose
>> these in a friendly way - but with our cross platform concerns that
>> might not be a good idea (e.g. I'm not familiar with windows).
>
> Providing Network.Windows and Network.Linux and Network.BSD etc modules
> would work fine for non-portable platform-specific features (of which there
> are many).

I think this makes sense. I read some slides from a presentation on
the next Java file API. The realization the Java community seemed to
have come to is that you need to offer APIs with both a cross platform
part and a platform specific part, preferably in such a way that both
can coexist somewhat peacefully (i.e. not two completely separate
class hierarchies).

Cheers,

Johan