On Thu, Aug 02, 2018 at 12:17:26AM +0200, Daniel Stenberg wrote:
> Here's my thoughts:
>
> https://github.com/curl/curl/wiki/URL-API
>
> Good or bad? What would your application need and would this work for that?
> If not, how should we change it to make it better?

My first thought it that it's pretty long-winded. I can't think of many
situations where you might want only one part of a URL, like the port, but
don't want e.g. the host, or the query without the path. What was in the back
of my mind for such an API was something simple like:

  CURLUCode curl_url_parse(
      const char *url,
      char **scheme,
      char **host,
      char **port,
      char **user,
      char **password,
      char **path,
      char **query,
      char **fragment);
  CURLUCode curl_url_build(
      char **url,
      const char *scheme,
      const char *host,
      const char *port,
      const char *user,
      const char *password,
      const char *path,
      const char *query,
      const char *fragment);

which simply splits an URL into its constituent parts and puts it back together
again. Your proposal makes me realize that a bitmap options argument would also
be good to allow some configuration of that process.

But maybe this is too simplistic. Using a handle-based approach as you do lets
you cleanly add additional functions to, e.g., iterate over individual
parameters in the query part, or over parts of the path (although that could be
done with my simple proposal with another function that operates on the query
part directly). Additional functions for handling specific URL schemes more
easily might also be welcome and could be added later, like one to directly
return an IMAP mailbox name from an IMAP URL. The handle-based approach makes
it easier to manage URLs; if all parts of the URL aren't needed at the same
time, the application doesn't need to keep 8 variables lying around to hold
them all.

A couple of things missing from in your proposal are handling of the fragment
part of the URL, and support for unescaping and possibly un-plussing query
parts (changing plusses to spaces), i.e., turning a URL into something useful
as-is in an application. I'd also move the "set" part of the name before what
it's setting, so it's more like curl_easy_setopt.
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html
Received on 2018-08-02