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, à 04 h 27, Lynn <kja...@gmail.com> a écrit : > Good timezone! > > On Thu, Jun 16, 2022 at 11:44 PM Pierrick Charron <pierr...@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 >
