Changing the API of the network package to use ByteStrings instead
johan.tibell at gmail.com
Sun Oct 31 11:38:25 EDT 2010
Now when network-bytestring is merged into network, the next natural
step would be to slowly deprecate the String based functions for
sending and receiving data in favor of the ByteString based ones.
This will necessarily be a long process, as lots of code depend on
these functions. Still I'd like to figure out a long term plan for
completely removing the String based functions from the API, or at
least deprecating them.
In the long run I'd prefer not to have a separate ByteString API
(under Network.Socket.ByteString) but to actually change the type of
e.g. recv in Network.Socket. This would make the API smaller, making
it easier to maintain and easier to understand. If that's not
feasible, I'd at least like to add DEPRECATED pragmas to the String
based functions to encourage the use of the ByteString based ones.
I see two basic approaches:
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
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.
Is 1 even possible/desirable? What would a more concrete plan look like?
More information about the Libraries