On Thu, Jan 17, 2013 at 1:37 PM, Graham Klyne <GK@ninebynine.org> wrote:

I don't want to be defensive, but I'd like to know what criteria would be satisfied by "a decent URI library that we can bless".

Network.URI is well-written, has a (mostly) acceptable API, and has tests, but facts on the ground have changed since you wrote this module in 2004. These days, the use of String in text-processing code is pretty close to disqualifying IMO. My criteria for a "decent URI library that we can bless" would be:

* datatypes and primitive functions using ByteString and/or Text, with parsing and rendering functions working both on Text and on utf-8-encoded ByteStrings

* a faster parser. I just plugged Network.URI's parser into criterion and got a timing of 12µs to parse a 52-character URI. Switching the benchmark to use a 365-character URI causes the time to balloon to 85µs. That's looking pretty linear at roughly 4MB/s throughput. As a data point, on the same machine my work-in-progress Snap branch based on io-streams can parse a 365-byte HTTP request in 1.8µs (about 190 MB/s), and that's running through a bunch of streaming IO gunk.

As an implementation of RFC 3986 [1] (the current definitive specification of a URI), I believe Network.URI is fairly complete. I'm sure there are aspects that might be considered poor style, poorly implemented, lacking some useful functions, or poor API design, but nobody's really said what they are (*). And I'd suggest that all but the final one of those criteria are fixable in an existing library.

Fixable yes, fixed by anyone yet? no. Michael's uri-conduit has the "correct" types, but that library is under-documented, incomplete compared to Network.URI, and there's no way the canonical URI library should be depending on conduit.

--
Gregory Collins <greg@gregorycollins.net>