[Haskell-cafe] Re: Cleaner networking API - network-fancy

[Johan Tibell]

On Thu, Aug 13, 2009 at 8:09 PM, Thomas
DuBuisson<thomas.dubuisson at gmail.com> wrote:
> I'm considering putting not insignificant effort into reworking the
> Network API during HacPDX.  Assuming Johan agrees with the changes
> (and I don't know exactly what those are yet), I'd like to leave
> Network.Socket for general use and rework the Network module to allow
> easier TCP/UDP sending and receiving, binding to particular IP
> addresses, using bytestrings, receiving data with IP Headers, and
> sending with IP headers.  Multicast is another good idea that should
> be in there.

Designing a correct and usable socket API is difficult. There are lots
of corner cases that are easy to get wrong. For example, the current
socket API always throws an EOF exception if recv returns a zero
length string even though a zero length return value only indicates
EOF when using TCP! Furthermore, the current API uses Strings which
makes no sense.  The library is poorly documented and lacks test
(compare it to e.g. Python's socket module).

There are other pitfalls as well. If you only cover parts of the BSD
API you will alienate a fraction of your users who are forced to write
their own bindings, not an easy task, especially if you want the
binding to be cross platform. This applied to any OS binding.

My best advice would be to form an special interest group (SIG) and
iron out the details. This doesn't have to be anything terribly
formal. Just a bunch of people who are interested in improving things.

The SIG could keep a wiki with the current design. This makes it
easier for both the members and other interested developer to review
the design and find flaws.

>> In general, the community would probably benefit if all these small
> packages (network, network-data, network-fancy, network-bytestring,
> network-multicast, network-server) gave way to fewer, more complete
> packages.

I absolutely agree. Hackage has increased the number of libraries a
lot, which is great. However, great libraries often come out of peer
reviews and attention to detail.

As for network-bytestring, it is slated to be merged back into network
under Network.Socket.ByteString if it passes community review.

> Right now the thought has came to me that the cleanest, most uniform
> method might be to have a Config data type with all these ideas as
> options and use a single 'connect', 'listen' or 'receive' function for
> all the different protocols and their various options.  I'll think on
> it.

Write a wiki and explain how nicely this idea solves some of the
current issues. That would be a good start.

Just my 2 cents,

Johan