Potential Network SIG

[Thomas DuBuisson]

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