Changing the API of the network package to use ByteStrings instead of Strings

[Ian Lynagh]

On Sun, Oct 31, 2010 at 04:38:25PM +0100, Johan Tibell wrote:
> 
> 1. Warn people of the upcoming change e.g. 6 months in advance, and
> then just change the types as part of a HP release. Delete the
> *.ByteString modules.
> 
> 2. Deprecate the String based functions using pragmas, slowly move
> people over to the ByteString based ones. When everyone has moved
> over, change the types of the original functions to also use
> ByteStrings. Slowly migrate people back to the old functions (that now
> have a different type). Delete the *.ByteString modules.
> 
> To be honest, I don't think 2 will ever work. From experience, without
> a deadline, people wont move.

You can have an overlap period and also deadlines. e.g. if HP major
releases are yearly, then this would work for people wanting to support
2 major releases at all times:

HP 2011: Add Network.Socket.ByteString.
People wishing to support 2 major versions use Network.Socket.

HP 2012: Deprecate Network.Socket.
People wishing to support 2 major versions use Network.Socket.ByteString.

HP 2013: Make Network.Socket use ByteString.
People wishing to support 2 major versions use Network.Socket.ByteString.

HP 2014: Deprecate or remove Network.Socket.ByteString.
People wishing to support 2 major versions use Network.Socket.

For changing the behaviour of names (as opposed to adding new behaviour
with new names) this does get quite drawn out, though.


Another option would be to make a network-string package exporting
Network.Socket.String, which depends on network and either reexports
Network.Socket directly (for old versions) or wraps the ByteString
functions (for new versions). Then people can make their code use
network-string now (which also works with HP 2010), and migrate back
to network once it's a major release or 2 old.


Thanks
Ian