Hi all, and thanks Levi for your feedback, If you look at the first thread (Discussion about new Curl URL API and ext/curl improvements) you'll see that this was my first approach. I even proposed to "OOPify" the actual CurlHandle & co objects with "simple" methods like $ch->setOpt(). Anyone who reads the actual API can see this is the actual "philosophy" of the extension. It was designed (on purpose or not) as a thin wrapper over curl. But lets focus on URL API only !
With previous thread answers, I was under the impression that I really was the only one liking the approach of following the cURL api as much as possible and leaving the more high level API to things like Guzzle & co (for example by adding an Implementation of PSR-7 UriInterface using this API) since all the others parts of the API are done this way. I think it's important to have this new Curl URL API in 8.2 since it fixes security issues and that's of course not ideal but I would rather have an implementation that would not be my first choice, than not having it at all. What do you think ? I would love more people to give feedback on what they are expecting, if they don't care if they prefer one approach or the other and of course why ? I was thinking about doing a vote on this, but I'm not sure it's a good idea. What do you all think ? Regards, Pierrick Le jeu. 23 juin 2022, à 12 h 49, Levi Morrison <levi.morri...@datadoghq.com> a écrit : > On Tue, Jun 21, 2022 at 10:38 PM Pierrick Charron <pierr...@php.net> > wrote: > > > > Hi, > > > > Following our discussions we had on the subject of the new Curl URL API, > > and other curl improvements. I decided to only focus on adding the new > Curl > > URL API and put aside all other improvements. Here is the RFC that > reflects > > our current conversations. > > > > https://wiki.php.net/rfc/curl-url-api > > > > Feel free to give any feedback, concern or support :-) > > > > Regards, > > Pierrick > > IMO, this should mirror the low-level curl url API very directly. The > basis of my opinion is that we do not own libcurl; we are merely > adapting it for use in PHP. We cannot anticipate changes in their > design, nor do we have authority to do so if we feel something should > change. Touching it as little as possible makes it easier to track > upstream changes, etc. > > Based on that, I think the naming should be closer to libcurl.: > - CurlUrl::URL_ENCODE should be CurlUrl::URLENCODE > - CurlUrl::URL_DECODE should be CurlUrl::URLDECODE > > And so on, only differing if necessary because something is a reserved > word. The API should be as exact as possible to what libcurl provides. > The "helpers" getHost, getPassword, etc should be removed and should > expose `curl_url_get` more directly. > > Of course, it should be object based instead of resource based, but that's > it. > > A nicer API can be built on top of it, but I don't think that's the > role this particular API should play. >
