On Thu, Aug 13, 2009 at 8:09 PM, Thomas
DuBuisson
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