Proposal: splitting the network package
GK at ninebynine.org
Thu Jan 17 10:20:17 CET 2013
I'm late picking up on this. I agree the Parsec dependency means it makes sense
to separate the URI package from other network functions. I don't know if
there's a strategy for backwards compatibility of existing software that uses
On 09/01/2013 12:17, Conrad Parker wrote:
> Yes, but then the "uri" package currently only defines one module, Text.URI:
> which is mostly similar and incompatible with Network.URI:
> Network.URI more completely implements the RFCs in that it handles
> relative and absolute URIs, and URI normalization.
> Text.URI includes a few functions for parsing (key,value) pairs for
> CGI query parameters, which iirc is not actually part of the URI
> specification, but rather part of the CGI conventions. I think these
> query parameters are better handled by the "cgi" package, or by any of
> the web frameworks (Yesod, Snap etc.).
> I think the only sensible way to use the "uri" package name would be
> to replace it (ie. remove Text.URI and add Network.URI).
FWIW, when I originally implemented URI, the interface was based on an existing
package, but I don't recall exactly which. Some changes were made to
accommodate additional functionality, but with new function names. Old function
names were retained, but deprecated, for backwards compatibility.
I mention this because it suggests a possibility that the newer package might be
tweaked to be a possible compatible replacement for the other.
At this stage in Haskell/HP life, I'd place a high premium on backwards
compatibility - having existing software break because other packages don't pay
sufficient attention to this issue is a factor that IMO impedes wider take-up of
Haskell as a serious application development platform. I see this discussion is
a symptom of that.
More information about the Libraries