Re: Potential Network SIG

On Mon, Aug 24, 2009 at 8:00 PM, Bryan O'Sullivan wrote:

On Fri, Aug 21, 2009 at 9:49 PM, Thomas DuBuisson 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