Excerpts from Thomas DuBuisson's message of Sat Aug 22 07:49:58 +0300 2009:
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. If you want to partake then this e-mail if your heads up. If there is some formal method of setting up a Haskell SIG then please let me know.
Sounds good, some notes below.
1) Separate low level functions / bindings from high level / productive code by placing each in different modules.
Good.
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).
The limitation to one IP-version is a runtime issue not a compile time one. All the platforms may support either IPv4 or IPv6, both or none depending on the machine the binary is run on. I think it should be possible to say "use v4", "use v6" and "use something" on all target platforms. A typeclass might work fine if designed correctly. Also a typeclass makes extensions easier if designed carefully.
3) Use Bytestrings (and have corrosponding .Lazy modules) for efficiency. As in network-bytestring, any new API should be performance concious enough to avoid String.
Ambivalent here. Does it make more sense to have a send :: StringLike s => ... or sendS :: String -> ... sendBS :: ByteString -> ... sendLBS :: L.ByteString -> ... Also if we have separate functions we need yet another set of functions when Text is ready.
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).
Most of these seem to be for the low level binding?
5) Separate IO-less data declarations from IO and any platform dependent code in different packages.
Would create lots of nearly identical implementation packages. Most of the implementation differences across platforms are quite small.
6) Integrate with the rest of hackage. This means instance of PrettyClass, Parsec, and Binary. I noticed a number of parsing utilities for IP addresses - lots of duplicated effort here.
Sounds good. - Taru Karttunen