Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:118149 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 66373 invoked from network); 1 Jul 2022 08:36:33 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 1 Jul 2022 08:36:33 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 61A42180212 for ; Fri, 1 Jul 2022 03:28:16 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS24940 176.9.0.0/16 X-Spam-Virus: No X-Envelope-From: Received: from chrono.xqk7.com (chrono.xqk7.com [176.9.45.72]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Fri, 1 Jul 2022 03:28:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bastelstu.be; s=mail20171119; t=1656671293; bh=/3a2hmNv1AFqwSMYb+KX3efvtoFe2FLOHRIdgBfXyp8=; h=Date:Subject:To:References:From:In-Reply-To:From; b=mQ2IBcb8l7iAaaPSLQRx0spbk+mn3ousff5TBQXtpYgUBG6sxHZP7bXpMEvvSqhgk MqlQUClZU1W+LcVK9aSYHwOjCkAKye4NKeicf65Af7iUSl72HkQXU4MapjvYWuNz1J rsrikTFjEAn+6aO9FofvW9YRwTFpFp9X4klbY4kOpTVmgTUiDT/l2KsxZtlCBDQrwg cL/sLm7lnyX4oIEK4H/60/i36tL+9D+Elp44cu611LYK1V72eC4bqbjTHm3/6sVTsf sIj+d0DbtjD7471EfxHTNMjpJp5Fi0oXzhYWUNbfPyL7qOXyQ//MK8Pc+NuyrE/Wzl OnA3qbtmUwlPA== Message-ID: <544ebd0c-b113-0132-aed9-f0f6d3dc1658@bastelstu.be> Date: Fri, 1 Jul 2022 12:28:11 +0200 MIME-Version: 1.0 Content-Language: en-US To: Rowan Tommins , PHP internals References: <7CB0EB0B-700D-49F6-8223-00A9B16F463B@php.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [PHP-DEV] [RFC] [Under Discussion] New Curl URL API From: tim@bastelstu.be (=?UTF-8?Q?Tim_D=c3=bcsterhus?=) Hi On 7/1/22 12:07, Rowan Tommins wrote: > My concern is rather the opposite: if it is not obvious *to someone writing > PHP code* how the API should be used, there is a higher chance of them > using it incorrectly, and introducing errors. > > A good example of this mindset is the password_* functions: they do not > expose the options of underlying implementations, they present an > easy-to-use *opinionated* set of behaviours, that solves a common use case > for their audience. They allow users to "fall into the pit of success", > because the easy thing is also the correct thing. The difference to me is that "curl" is a well-established library with an existing API. By faithfully representing the original API (e.g. the naming of the options/flags), I can leverage the existing documentation or Stack Overflow Q&A to learn what exactly a specific option does. This would be different for an "url" or "http" or "uri" extension. That one might use cURL currently and might use https://github.com/uriparser/uriparser in a future version if there are good arguments to change the underlying library. It would just guarantee you that it can process URIs correctly according to whatever API one creates. The password_* family uses such a generic term: "password". It does not pretend to be "libargon2". In other words: If it says "curl" on the box, then I expect to have "curl" within the box. > However, to me at least, it's not entirely clear who the target audience > for this API is, what tasks it should be making easy, and what correct > usage looks like. Just providing a bunch of functions, in whatever form, > doesn't provide security unless users can understand how to use them > securely. Best regards Tim Düsterhus