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