yes, I think passing around a struct with this information (and able
to get uri from its parts) would be useful would be more useful then
just direct url construction ... that way one could represent a common
base uri and modify it by just setting new path (in that respect we
may want ability to manage segments, query or fragments of a uri). +1
for unescape/escape.

Jim

On 2 August 2018 at 07:36, Dan Fandrich <dan_at_coneharvesters.com> wrote:
> 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
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html
Received on 2018-08-02