Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:118080
MIME-Version: 1.0
References: <CAOfKkdTjPiZHnSHuag_+fmFK-1Advh2-vfDgbJBXEmK=72NB0g@mail.gmail.com>
 <CAAKU0um7-7KZnBibwQxkvm_Kq8a264BZYOPc8G2jfax_43odjQ@mail.gmail.com>
In-Reply-To: <CAAKU0um7-7KZnBibwQxkvm_Kq8a264BZYOPc8G2jfax_43odjQ@mail.gmail.com>
Date: Fri, 24 Jun 2022 09:49:27 -0400
Message-ID: <CAOfKkdTiptR5i6+9x4UnV0sZeZh2Q8u167onzEHVwMq1Cv-E5A@mail.gmail.com>
To: Levi Morrison <levi.morrison@datadoghq.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000067c42705e231d7cf"
Subject: Re: [PHP-DEV] [RFC] [Under Discussion] New Curl URL API
From: pierrick@php.net (Pierrick Charron)

--00000000000067c42705e231d7cf
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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, =C3=A0 12 h 49, Levi Morrison <levi.morrison@datadogh=
q.com>
a =C3=A9crit :

> On Tue, Jun 21, 2022 at 10:38 PM Pierrick Charron <pierrick@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.
>

--00000000000067c42705e231d7cf--