> There's a good chance we end up using curl for the dataset project We'll need curl in our toolchain at some point for interacting e.g. with Google Cloud Storage [1]
[1]: https://github.com/tensorflow/tensorflow/blob/master/tensorflow/core/platform/cloud/gcs_file_system.cc On Wed, Feb 27, 2019 at 10:17 AM Antoine Pitrou <solip...@pitrou.net> wrote: > > > I've opened a couple issues for cpp-netlib. Let's how the maintainer > responds. > > Otherwise I agree uriparser sounds better. > > Regards > > Antoine. > > > On Wed, 27 Feb 2019 10:12:24 -0600 > Wes McKinney <wesmck...@gmail.com> wrote: > > Seems like uriparser might be a better choice, but I haven't looked > > into the C++ uri library to see how annoying maintaining a patched > > version would be > > > > On Wed, Feb 27, 2019 at 10:06 AM Antoine Pitrou <solip...@pitrou.net> wrote: > > > > > > > > > Hello, > > > > > > As part of ARROW-4651, we would need to have a URI parsing library in > > > the C++ project. > > > > > > One such library is https://github.com/cpp-netlib/uri, it's based on a > > > previous proposal for the standard C++ library. It has no dependencies > > > except boost::algorithm. > > > > > > One problem is that the library ships its own backports of > > > `std::string_view` and `std::optional`. We already have a backport of > > > `std::string_view` in our source tree (it seems more complete). So we > > > would need to patch the uri library to use our backport. Maintaining > > > the patch will be a bit annoying. > > > > > > Another possibility is to use the C-only, no-dependencies uriparser > > > library (and write a small C++ wrapper around it): > > > https://uriparser.github.io/ > > > > > > Regards > > > > > > Antoine. > > > > > > > > > > >
