Potential Network SIG

[Simon Marlow]

On 22/08/2009 05:49, Thomas DuBuisson wrote:
> 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.

Idealogically speaking, this is not a choice you should make in the 
network library.  The network library should deal with setting up 
sockets, and delegate the actual I/O to the I/O library.

Right now, that means making Handles from Sockets (which is something 
the current network library provides).  And then you use the bytestring 
library to write bytestrings to the Handle.  In the future we'll have a 
way to write text to a Handle too.

Now, I wouldn't be surprised if this doesn't cover all the use cases. 
Maybe people want to use the low-level send/recv.  But I expect that for 
most applications, going via Handle will be the right thing, and we 
should look at how to accommodate the other use cases.

Cheers,
	Simon