Proposal: splitting the network package

[Conrad Parker]

On 17 January 2013 23:51, Gregory Collins <greg at gregorycollins.net> wrote:
>
> 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.

c'mon, it's not like anyone needs to go parsing billions of URIs in a hurry.

But seriously, Graham's URI module was one of the things that
convinced me about Haskell in the first place: that the libraries are
so well-written that they are the reference implementation of a
standard. Browsing the docs for Network.URI and the time library
really convinced me that people in Haskell land care about doing
things correctly.

Sure, someone should write a faster version with more fashionable
types, but I'd really view that as an incremental improvement.

Conrad.