Potential Network SIG

[Johan Tibell]

Hi,

Thanks for getting this started Thomas. I've added some of my thought inline:

On Sat, Aug 22, 2009 at 6:49 AM, Thomas
DuBuisson<thomas.dubuisson at gmail.com> wrote:
> 1) Separate low level functions / bindings from high level /
> productive code by placing each in different modules.

I think this is crucial to avoid having a percentage of the users have
to write their own bindings because we simplified away their use case.
In order for the library to be extensible it should also allow access
to the underlying file descriptor. That way someone could e.g. write a
library for the 'select' system call and have it work with sockets.

> 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.

Agreed. String is also semantically the wrong types. The OS socket API
doesn't understand Unicode.

> 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 must disagree here. We don't want hard coupling to lots of other
libraries. i.e. we don't need convenience functions like:

get :: Socket -> Binary a

These ends are better reach by the client writing the glue code. It's
easy to get a combinatorial explosion in the number of functions if we
try to provide an integration point for each library out there.

> 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.

I think the best way to proceed is to discuss specific. Lets dig up
some examples of things that are suboptimal in the current design and
write down some alternative designs on a wiki page.

Cheers,

Johan