Proposal: splitting the network package

[Gregory Collins]

On Thu, Jan 17, 2013 at 1:37 PM, Graham Klyne <GK at 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.

G
-- 
Gregory Collins <greg at gregorycollins.net>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20130117/55bcbf7c/attachment.htm>