Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:117972
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>
In-Reply-To: <CAOfKkdSWhQ5-wbnnWzb74VknGNVSM+2+5-sMoc-_yOEzk4JFFQ@mail.gmail.com>
Date: Fri, 17 Jun 2022 10:27:12 +0200
Message-ID: <CANS-=pdrGap4ep=14DL97xPDOdM0+6eQszy8JE0c8+c8v8rxdQ@mail.gmail.com>
To: Pierrick Charron <pierrick@php.net>
Cc: Larry Garfield <larry@garfieldtech.com>, php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000fff1e905e1a086a5"
Subject: Re: [PHP-DEV] Discussion about new Curl URL API and ext/curl improvements
From: kjarli@gmail.com (Lynn)

--000000000000fff1e905e1a086a5
Content-Type: text/plain; charset="UTF-8"

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* OOP
> 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 designed
> 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 part
> that is a thin wrapper and another part that is a "remodeling" of the API ?
> (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 procedural
API for cURL is really annoying to deal with, and I think it would be worth
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 in
my opinion. I know that both the Symfony Http Client and Guzzle are popular
libraries, perhaps design wise they could serve as an inspiration?

I'm personally not too experienced with cURL nor the level of details that
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 spending
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 beneficial for
security and reduces bugs. The reason being is that even if we have the
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 just
end up in way too many Stack Overflow questions.

Perhaps it is best to split this into 2 separate RFCs?

Regards,
Lynn

--000000000000fff1e905e1a086a5--