Network.URL

[Simon Marlow]

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