Potential Network SIG

[Bryan O'Sullivan]

On Fri, Aug 21, 2009 at 9:49 PM, Thomas DuBuisson <
thomas.dubuisson at gmail.com> wrote:

>
> Johan suggested starting a SIG to hammer out a design for a new
> Network API seeing as the current API, a straight-forward Berkeley
> binding, doesn't seem to please anyone in a Haskell context.


Thanks for getting the conversation started!

Your agenda is very ambitious, which worries me a little. As a "how to get
things moving" tip, I'd very strongly suggest trying to make progress on the
lowest level bindings first, as they will be the most concrete, and the
least likely to provoke prolonged discussion and disagreement.


> 2) Maintain type safety by using type classes for most things.
>
> Unlike Network.Fancy and Network.Socket (which have IPv4 and IPv6 as
> constructors of the same data type), I think we should allow for the
> possibility that some users of the library will be limited to just one
> IP version without resorting to partial functions.  I suggest type
> classes to cover this aspect (class Address, class Port, etc).
>

I don't understand what this might mean. Code examples or type signatures
are going to be much easier to follow than English descriptions.


> 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.


> 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).

As for providing instances for the likes of Binary, there are good reasons
not to do that in the core network package, because it will drag in
dependencies on quite a few third-party packages that are either not in core
(binary) or have questions over their futures (Parsec).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/libraries/attachments/20090824/3e3bf4b4/attachment.html