On 12/06/2009 18:10, Iavor Diatchki wrote:
I agree that there is overlap between the two. I specifically wrote Network.URL because of some problems that I encountered while trying to use Network.URI on a project. My biggest problem was that Network.URI does not abstract away from representation issues, so one runs into all the usual PHP type of problems like forgetting to URL encode/decode, or doing it multiple times. It is (alsmost) like just working with Strings. Here is an example:
show (URI "http:" Nothing "my?path" "" "") "http:my?path"
which is incorrect in a number of different ways.
Network.URL uses a different approach where the basic design principle is that programmers work with URLs as ordinary Haskell values, and then there are functions to convert to/from Strings/Bytes, which take care of representation issues. Here is an example:
exportURL (URL HostRelative "my?path" []) "/my%3fpath"
So, my vote (unsurprisingly) would be to obsolete/replace Network.URI. I am a bit worried that this might break a lot of code. On the other hand, recently we have been a lot more strict about specifying the precise dependencies for packages, so perhaps there won't be much of an issue?
I take your point about Network.URI not doing escaping robustly, obviously that's important. Also, you clearly have more experience using these libraries than I do. I did write the original Network.URI, but it has been rewritten by Graham Klyne since then. One thing I'm concerned about is that a lot of effort went into Network.URI to ensure that it complied with the relevant RFCs, and it has some pretty comprehensive tests. http://darcs.haskell.org/packages/network/tests/uri001.hs Is Network.URL this well tested? The main difference I noticed between the two libraries is that Network.URI has relativeTo :: URI -> URI -> Maybe URI which doesn't have an equivalent in Network.URL. Any merged library should have this (and this function is where most of the complexity is, IIRC). Cheers, Simon