Hi all, 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 Network.URI. On 09/01/2013 12:17, Conrad Parker wrote:
Yes, but then the "uri" package currently only defines one module, Text.URI:
http://hackage.haskell.org/packages/archive/uri/0.1.6/doc/html/Text-URI.html
which is mostly similar and incompatible with Network.URI:
http://hackage.haskell.org/packages/archive/network/2.4.0.1/doc/html/Network...
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. #g