Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:117974
MIME-Version: 1.0
References: <CAOfKkdRzoo7JuD07F8nkZBYvS5eDMiV2r6cNV-FgeLxBrdCsiQ@mail.gmail.com>
 <b8333cb6-eaa0-4170-a3ba-29eadb2fd8fa@www.fastmail.com> <CAOfKkdSWhQ5-wbnnWzb74VknGNVSM+2+5-sMoc-_yOEzk4JFFQ@mail.gmail.com>
 <CANS-=pdrGap4ep=14DL97xPDOdM0+6eQszy8JE0c8+c8v8rxdQ@mail.gmail.com>
In-Reply-To: <CANS-=pdrGap4ep=14DL97xPDOdM0+6eQszy8JE0c8+c8v8rxdQ@mail.gmail.com>
Date: Fri, 17 Jun 2022 08:17:07 -0400
Message-ID: <CAOfKkdQ6PBY8E0SErGPaFLZaHi6ERUSrTARdVEwrEfGy5aNkLA@mail.gmail.com>
To: Lynn <kjarli@gmail.com>
Cc: php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000053cb2005e1a3bcc3"
Subject: Re: [PHP-DEV] Discussion about new Curl URL API and ext/curl improvements
From: pierrick@php.net (Pierrick Charron)

--00000000000053cb2005e1a3bcc3
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Lynn,

You have to be careful, even though most developers associate curl with an
http client and only use this feature, it's only part of what it is. It's
a multiprotocol file transfer library that supports DICT, FILE, FTP, FTPS,
GOPHER, GOPHERS, HTTP, HTTPS, IMAP, IMAPS, LDAP, LDAPS, MQTT, POP3, POP3S,
RTMP, RTMPS, RTSP, SCP, SFTP, SMB, SMBS, SMTP, SMTPS, TELNET and TFTP.

Again I'm not against a new extension that deals nicely with HTTP and has a
super nice intuitive OOP API. But for me that's just not the curl
extension. That would be a different project like ext/http.

Pierrick

Le ven. 17 juin 2022, =C3=A0 04 h 27, Lynn <kjarli@gmail.com> a =C3=A9crit =
:

> Good timezone!
>
> On Thu, Jun 16, 2022 at 11:44 PM Pierrick Charron <pierrick@php.net>
> wrote:
>
>> About making a "Good OOP API", of course the goal is to make a *Good* OO=
P
>> API. But there are things to take into consideration. The proposal here =
is
>> yes to expose the new Curl URL API which is quite small, but also to
>> modify
>> the existing curl API to make it a little bit more digest for developers=
.
>> Good or bad the existing ext/curl is here and will continue to exist for
>> quite some time. It was designed (maybe on purpose or not) to be a low
>> level API with tons [1] of low level features, and it was clearly design=
ed
>> as a thin wrapper/bridge over libcurl. I mean the fact is currently each
>> constant is the exact same one as in libcurl, and each function is a
>> wrapper over the exact same function in libcurl. Is it OK to have one pa=
rt
>> that is a thin wrapper and another part that is a "remodeling" of the AP=
I
>> ?
>> (This is not a rhetorical question, I really ask myself the question).
>>
>
> I'm not a C developer, and the only other place I've ever used cURL is on
> the command line. I honestly care very little for it resembling whatever
> the C library is, as C is a different language with no OOP. The procedura=
l
> API for cURL is really annoying to deal with, and I think it would be wor=
th
> designing an OOP counterpart. I think most of this would go into a new
> design for setting options among things, as a list of constants with
> possible values is one of the worst ways to have to configure something i=
n
> my opinion. I know that both the Symfony Http Client and Guzzle are popul=
ar
> libraries, perhaps design wise they could serve as an inspiration?
>
> I'm personally not too experienced with cURL nor the level of details tha=
t
> go into http libraries, but I do see this as an opportunity to make a
> really good implementation from scratch. In my opinion it's worth spendin=
g
> some time on this.
>
> Larry said:
>
> Like most of the responders so far, I would say skip the procedural API,
>> just go OOP and be done with it.
>>
>
> I'm okay implementing one last feature in the procedural API if it's
> really desired to have this functionality, especially if this is benefici=
al
> for security and reduces bugs. The reason being is that even if we have t=
he
> best possible OOP library for cURL, every single procedural API would
> benefit from this change without having to completely rewrite their
> implementation, which will be a problem if the OOP interface isn't just a
> 1:1 copy into object form. That said, we should avoid having: cURL
> procedural + cURL procedural in objects + cURL OOP. Having 2 different
> object based libraries to do the same thing PHP is confusing and will jus=
t
> end up in way too many Stack Overflow questions.
>
> Perhaps it is best to split this into 2 separate RFCs?
>
> Regards,
> Lynn
>

--00000000000053cb2005e1a3bcc3--