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 <[email protected]> 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
