On Thu, 2 Aug 2018, Dan Fandrich wrote:

> 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);

I find that API a bit awkward due to the large amount of arguments. That style
could also be supported with:

   CURLUCode curl_url_parse(const char *url, struct curlurl *store);

... and hake 'struct curlurl' be a public struct that gets filled in with
those eight char pointers. But I'm not too fond of doing public structs like
that as they're so hard to change in the future.

I also comtemplated having the API work like this:

  curl_url_get(CURLURL *handle, CURLPIECE what, char **piece, int flags);
  curl_url_set(CURLURL *handle, CURLPIECE what, char *piece, int flags);

... and have the second argument specify what part to extract or set instead
of doing one function for each. In fact, I think I now prefer this way since
it reduces the amount of function calls needed and makes the get/set calls
very uniform.

> Your proposal makes me realize that a bitmap options argument would also be
> good to allow some configuration of that process.

It's either that or taking a firm stance of what the "correct" response should
be in those cases, but I think it might be hard to have one single correct
behavior everywhere...

> 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.

I've grown to like handle-based APIs since they keep things flexible for the
future...

> A couple of things missing from in your proposal are handling of the fragment
> part of the URL

Oops!

> 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.

Yeah, I sort of left that out as a start as I wasn't really sure if that
should be part of this API, but I think you're right that users will probably
appreciate exactly that ability.

> I'd also move the "set" part of the name before what it's setting, so it's
> more like curl_easy_setopt.

Fair enough!

-- 
  / daniel.haxx.se
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette:   https://curl.haxx.se/mail/etiquette.html