Potential Network SIG

[taruti]

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