Potential Network SIG
johan.tibell at gmail.com
Mon Aug 24 15:48:59 EDT 2009
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
>> 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
More information about the Libraries