Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:118643 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 84422 invoked from network); 16 Sep 2022 14:35:17 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 16 Sep 2022 14:35:17 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id D08221804FF for ; Fri, 16 Sep 2022 07:35: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=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS15169 209.85.128.0/17 X-Spam-Virus: No X-Envelope-From: Received: from mail-ua1-f43.google.com (mail-ua1-f43.google.com [209.85.222.43]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Fri, 16 Sep 2022 07:35:16 -0700 (PDT) Received: by mail-ua1-f43.google.com with SMTP id u14so7963632ual.3 for ; Fri, 16 Sep 2022 07:35:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=basereality-com.20210112.gappssmtp.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date; bh=y+TFntAJ2jpy7WpHp+3HNcuz6egV7uME7siTd9A84tc=; b=t8V08WfH6tpsfYnr7x2gjfSmFwppKRCRW5KhQ+NA6A91FyWNnR8z/wCI3nltzkUWiz ++aw5ZYZSrMsY+Vrlpe9jq7Q1p/3Z1w39YYLzy0RFVDK2ZzcMv/GQGeggJuf2ZFlqqTW dsWvA6kolWxAeFP6wtjxeJmL8pIzmkWtR9U/CII7T4Pi3V8AHfHT8euvP5OFxu8CNYRh zzKVu8ueIYLGfm+04KZUF6PSeFUPsASrMqeHCl9BbLV13+aHiX2WbJuUGR97x4Zldow2 AJzZTMsIjbY9XGowD7B8TefYduehbIdhr/z8rHFY71NtK6MixWHZqiIPHr734KqeYKid hepw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date; bh=y+TFntAJ2jpy7WpHp+3HNcuz6egV7uME7siTd9A84tc=; b=dQEal9MeacAebQY/gj3sk3nVbsdbmjL+bCbuTguIgqVKMYmXz5OO8pX+oijlI+A/HM Y0jcOFbHBnP7ri4I3tR+KBRWzq2JmMA3ORk10dcAuBTLLuzdCoGLMMfHx6QJNQTVNPsi eJ05RmdYGlAv3JTcel2esPhSSXejWxKyZSeMx+80PKuMyrcF/Z9gzCIQv9jFnBXOI3Ng LAzSmMjW6fbMl6Mf8FiRZajHpKJZROD3LSxDDn5ExGxksm05AVWDMLbu+SMrZ8+z7iuh W2cXHw7k5reZt+/o1LtyK9ui+0EVsJVrESajhpY9xAhQuDTsT/4Fez0A8wv+Yns2W7X9 wgGQ== X-Gm-Message-State: ACrzQf1mPJbV0o+eLNXGzj0jUIjwioYQQ58S72H3ec8xPb4PwGakVtZT x/oipT2F1czbd5ddtEM9xs00JQdKno1AZq1hDcm8IA== X-Google-Smtp-Source: AMsMyM5BMQpGkEb5Hni7e6254b1mMawmbLTc0EfXYvi5PchFzzIsvUW58nXw6qp1JtQft46Sn+ETlIUCoO9oErsZ+YQ= X-Received: by 2002:a9f:30c2:0:b0:394:8df8:557 with SMTP id k2-20020a9f30c2000000b003948df80557mr1974155uab.6.1663338915414; Fri, 16 Sep 2022 07:35:15 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: Date: Fri, 16 Sep 2022 15:34:59 +0100 Message-ID: To: Timmy Almroth Cc: internals@lists.php.net Content-Type: text/plain; charset="UTF-8" Subject: Re: [PHP-DEV] RFC: StreamWrapper Support for glob() From: Danack@basereality.com (Dan Ackroyd) Hi Tim, On Wed, 14 Sept 2022 at 17:59, Timmy Almroth wrote: > > Hello everyone. I would like to announce that the RFC for "StreamWrapper > Support for glob()" is now ready for Discussion. The RFC has: > Final patch will be produced ... if this RFC is approved. I think that although the RFC discussion can go ahead without a patch, it would be better to have a patch before it went to vote, as there seem to be quite a few hidden details that might not be able to be made to work. The RFC has: > Consistently implement StreamWrapper support for glob(). Example: > glob('vfs://*.ext') but as noted in the PR (https://github.com/php/php-src/issues/9224), where cmb69 wrote: > > In some cases it just makes no sense (e.g. compress.zlib:// and data://), in some > cases it is impossible (e.g. http://), and in some cases it still might be > impractical (e.g. ftp://). The exact details of edge cases probably need to be at least listed as people (well at least myself) would view a lack of those details as a reason to vote 'no', even if they thought the general idea was good. The RFC probably also needs to make an argument of why something that sounds like it would be a leaky abstraction should be in core (and so generating more support requests) rather than people using the already existing userland package (https://packagist.org/packages/webmozart/glob) which currently has over 10million installs. cheers Dan Ack