Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:118654 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 10782 invoked from network); 19 Sep 2022 14:19:56 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 19 Sep 2022 14:19:56 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 6FC6C180084 for ; Mon, 19 Sep 2022 07:19:55 -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.3 required=5.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE,RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_SOFTFAIL,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-yw1-f178.google.com (mail-yw1-f178.google.com [209.85.128.178]) (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 ; Mon, 19 Sep 2022 07:19:54 -0700 (PDT) Received: by mail-yw1-f178.google.com with SMTP id 00721157ae682-345528ceb87so340951517b3.11 for ; Mon, 19 Sep 2022 07:19:54 -0700 (PDT) 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=CToGlIrjB4TZo7YeaOR9n1x1W+plBwdGkyzjyagxrjw=; b=XKpeVJWmpmX1TkWL/hjVAj/Ao5Eyi5CxOvzf6VBj3ipI5hfBsJ39kFxNEuT+eEPtZJ UvouEMJxRlgiPv5S45TOUDx7xxdaafLGkOsV44XkIbifW5+tXqiOq4KaiOTtQe6n3ypr uVTvCLgdlfCo6Sv9QPu7EzRxXwlHi6t/S5Vm8RfZCnM+tx0fVhXcYatOZEtUm7rKt59O o43Dwg512Gig00P4TZSiyIfcJ2NiP05W7mRkhKnthWkX03B+XpexpDFo65kEV2wRV3Wq RDWkZPk8yVNBqcPEo3WlWZy4yynY86fnbl5tFhCVxBGqnNHlhjaFFFA7tw2eOHui0kgT YUmQ== X-Gm-Message-State: ACrzQf3CysbXQJq7M1w/SZndRnZouI1Ydimwo8SLUMomD/f53dLfFRp/ ap+WP08ey9e4rXC2MMIzmxAAgIEjFT/tR4lg0du4dQ== X-Google-Smtp-Source: AMsMyM4r0t56bba2Oj8r/oH2bMOiQWIYv/C042Y+NB0gqFKp9cc+i75HSObM9bRRkFo+1vYxfgAC6yJpCjLy2ApAIKA= X-Received: by 2002:a81:86c2:0:b0:332:a104:f7e4 with SMTP id w185-20020a8186c2000000b00332a104f7e4mr15046462ywf.505.1663597193099; Mon, 19 Sep 2022 07:19:53 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: Date: Mon, 19 Sep 2022 09:19:42 -0500 Message-ID: To: Timmy Almroth Cc: PHP internals Content-Type: multipart/alternative; boundary="000000000000be8e2405e9086747" Subject: Re: [PHP-DEV] RFC: StreamWrapper Support for glob() From: pollita@php.net (Sara Golemon) --000000000000be8e2405e9086747 Content-Type: text/plain; charset="UTF-8" On Sun, Sep 18, 2022 at 5:02 PM Timmy Almroth wrote: >> There's a PR linked, but we should define the actual goals/APIs etc... >> in the RFC itself as well as the numerous edge cases >> > I agree. If you wanna put it in writing I can put it in the RFC. For the > edge cases my proposal is to return that empty array like it does for any > invalid path today. We could leave a note or tip in the documentation, but > again then you might need to do so with scandir() and all the other > filesystem functions. > > @Sara let me know if you would like to take over this RFC? You are more > experienced than I am. > I don't. I'm split too many ways atm to take on a PHP RFC. I was using "we" in a more collective sense to mean "us as a project when writing any RFC". The mechanics of wiring in a method in a wrapper to be called as a proxy from a global function isn't hard. What's hard in this case is defining what is expected from that function, specifically what a typical user might expect. One might expect glob('https://www.php.net/*') to return all names of all root pages on the site, and perhaps all short aliases as well (which effectively includes all functions and classes). There's no way a StreamWrapper implementation can accomplish that in the general case, the protocol simply doesn't support it. But okay, we don't implement it for http(s), but maybe we do got ftp(s), and might as well let end users decide when they have a custom wrapper where it makes sense. Cool. I'm just saying write all that out and put it in the RFC. There's no need to know C or PHP's internal APIs to write that much. Write out the API from the user's point of view, what assumptions you're making about their use cases, and what risks are presented by cases like http(s) where we won't be able to pull off a meaningful implementation. -Sara --000000000000be8e2405e9086747--