I fully support this change, and would even appreciate a big warning (to be encoding-aware) on functions that send/receive Strings over the network. On Wed, Oct 27, 2010 at 6:03 PM, Johan Tibell wrote:

Hi all,

network-bytestring addresses two serious problems with the network package: performance and a semantically incorrect type for network data. Both problems are addressed by using ByteStrings instead of Strings in the types of e.g. recv and send. In addition, network-bytestring supports vectored I/O (also know as scatter/gather I/O) which yields better performance in many common use cases, such as HTTP servers.

The merge doesn't break any old code: it introduces new APIs under Network.Socket.ByteString and Network.Socket.ByteString.Lazy but leaves the old API intact. The network-bytestring package is also better documented and tested that the network package. The API is portable.

The network-bytestring package can be found at http://hackage.haskell.org/package/network-bytestring

Discussion deadline: 2 weeks

Johan _______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

On Wed, Oct 27, 2010 at 6:03 PM, Johan Tibell wrote:

Hi all,

network-bytestring addresses two serious problems with the network package: performance and a semantically incorrect type for network data. Both problems are addressed by using ByteStrings instead of Strings in the types of e.g. recv and send. In addition, network-bytestring supports vectored I/O (also know as scatter/gather I/O) which yields better performance in many common use cases, such as HTTP servers.

The merge doesn't break any old code: it introduces new APIs under Network.Socket.ByteString and Network.Socket.ByteString.Lazy but leaves the old API intact. The network-bytestring package is also better documented and tested that the network package. The API is portable.

+1! This is a very positive change. Anthony

On 10/27/10 6:03 PM, Johan Tibell wrote:

Hi all,

network-bytestring addresses two serious problems with the network package: performance and a semantically incorrect type for network data. Both problems are addressed by using ByteStrings instead of Strings in the types of e.g. recv and send. In addition, network-bytestring supports vectored I/O (also know as scatter/gather I/O) which yields better performance in many common use cases, such as HTTP servers.

The merge doesn't break any old code: it introduces new APIs under Network.Socket.ByteString and Network.Socket.ByteString.Lazy but leaves the old API intact. The network-bytestring package is also better documented and tested that the network package. The API is portable.

The network-bytestring package can be found at http://hackage.haskell.org/package/network-bytestring

Discussion deadline: 2 weeks

+1. My only request would be to update the documentation for the old network functions in order to (a) make them match the quality of the docs in network-bytestring, and (b) to warn people that they should be using the bytestring functions anyways. -- Live well, ~wren

On Wed, Oct 27, 2010 at 5:03 PM, Johan Tibell wrote:

Hi all,

network-bytestring addresses two serious problems with the network package: performance and a semantically incorrect type for network data. Both problems are addressed by using ByteStrings instead of Strings in the types of e.g. recv and send. In addition, network-bytestring supports vectored I/O (also know as scatter/gather I/O) which yields better performance in many common use cases, such as HTTP servers.

The merge doesn't break any old code: it introduces new APIs under Network.Socket.ByteString and Network.Socket.ByteString.Lazy but leaves the old API intact. The network-bytestring package is also better documented and tested that the network package. The API is portable.

Have you given any thought to having the Network.ByteString and Network.ByteString.Lazy modules re-export the symbols in the Network module? It isn't necessary, but it would make them nicer to use. Either way this sounds like a good idea. Antoine