I don't think either of us was actually proposing it for the HP, and
certainly not for this cycle. I was actually surprised that Mark mentioned
an HTTP client library at all, given that HTTP is already in the platform.
But if there's interest in replacing it in a later cycle, I would propose
http-client.
On Tue, Apr 8, 2014 at 7:11 PM, Carter Schonwald wrote: so it sounds like theres a clear agreement to not include a new http lib
in HP this cycle? :)))) On Tue, Apr 8, 2014 at 11:54 AM, Michael Snoyman On Tue, Apr 8, 2014 at 6:29 PM, Gregory Collins On Tue, Apr 8, 2014 at 5:10 PM, Michael Snoyman I know people have raised security concerns about using the tls package
due to lack of testing relative to OpenSSL, but I'm not sure if those
arguments are so valid given recent events[5]. Yeah, I've been meaning to mention this issue -- I have definitely been
among those in the past pushing for OpenSSL as the only sensible solution
(conventional crypto wisdom is that you stick to tried and true,
well-tested solutions) but I might change my tune on this. Sure, the
Haskell tls library might potentially be vulnerable to unknown side
chaining or timing attacks (and there is C code in there), but I don't see
much chance of buffer overflows leading to secret key disclosure (!) coming
out of our camp. Unfortunately the entire Haskell tls/crypto ecosystem doesn't obey the
Hackage package versioning policy and until this is fixed I think that
issue precludes it from being included in the platform. I'm sure you can guess that I disagree with this statement. But I also
find it absurd in the given context: the Haskell Platform package we're
discussing right now (cgi) doesn't follow the PVP! Beyond just trying to force the rest of the world to adhere to the PVP,
what actual reason is there to require Haskell Platform packages adhere to
the PVP? I assume you're referring to the fact that tls doesn't include
upper bounds on its dependencies, because it certainly *does* follow PVP's
versioning guidelines on its own version number. But once a package is
included in the platform, there's no opportunity for build failures since
the platform will be locking down versions of all its dependencies. So besides trying to find another means of enforcing PVP adherence on the
rest of us, what value is there in this new requirement? As far as HTTP clients go there is also http-streams (
http://hackage.haskell.org/package/http-streams) which is itself very
nice and (unsurprisingly) what I would vote for. Given that we already have
an HTTP client library in the platform (even though it's not really so
great) and there are multiple viable alternatives, I don't think we can
pick a replacement to go into the platform yet, especially if it would pull
in one of the streaming libraries. I've considered nominating io-streams
for inclusion into the platform (it's a very nice and high-quality library,
if I do say so myself) but I haven't because the matter simply isn't
settled yet and I don't think it's right to canonize one approach over the
others. http-client has no dependency on any streaming data library. The
codebase- while it's moved from a few different libraries over the years-
has been publicly available since 2010[1]. It has bindings for tls and
openssl, as well as interfaces for conduit and pipes. It has a large number
of packages on Hackage already depending on it (at least 104[2] via
http-conduit, though there are other libraries that depend on http-client
directly). None of this touches on the technical merits of the two
libraries; in particular, http-client provides a much more robust
connection sharing mechanism than what is available in http-streams. Michael [1] http://hackage.haskell.org/package/http-enumerator-0.0.0
[2] http://packdeps.haskellers.com/reverse/http-conduit _______________________________________________
Libraries mailing list
Libraries@haskell.org
http://www.haskell.org/mailman/listinfo/libraries