marlowsd at gmail.com
Mon Jun 15 07:16:31 EDT 2009
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" "" "")
> 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" )
> 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.
Is Network.URL this well tested?
The main difference I noticed between the two libraries is that
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,
More information about the Libraries