Hello All, If you are CCed it's because you are listed as a maintainer of a network-* package that I consider related to the Haskell network library. I'm hoping to roll much of the functionality of network-{bytestring, multicast, fancy} etc into a single package that the community will agree on (namely, "network"). 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. My thoughts on some important parts are below - I'm sure not everyone will agree as these thoughts directly contradict some designs found in current libraries. 1) Separate low level functions / bindings from high level / productive code by placing each in different modules. The low level bindings should remain available for those cases we fail to have the needed functionality in our high level packages. That said, I'm hoping to cover more than the 80% of users with any new design. 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). 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. 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). 5) Separate IO-less data declarations from IO and any platform dependent code in different packages. I've already got some work in this area via network-data. Not claiming its current design will stand the test of time, its just an example of keeping the data structures separate from any IO operations that will need platform specific work. 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. I'm currently looking at how the network library is being used - particularly when Network.Socket is invoked. So I guess I'll go sort through some of the source code for scurry, happstack, and adhoc-network. Thomas