RFC: StreamWrapper Support for glob()

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.

Whether a streamwrapper can be used with glob() or not is not a limitation
of the intended glob() implementation, but a limitation of the
StreamWrappers themselves. The problem already applies to scandir() today.
scandir('ftp://.../') would only resolve contents if the streamwrapper
supports it. Someone can substitute PHP's streamwrapper for ftp with one
that does resolve content. I'm not sure how many would attempt these border
cases, but the documentation could state some words of advice. We could
list what streamwrappers that work out of the box, or vice versa.

I would not change the way glob() returns data. For invalid paths or
streamwrappers it would just continue to return an empty array() like it
does today.

I edited the RFC to mention these edge cases and limitations. And how they
would be handled.
If you feel I missed something out I'm grateful if you wanna send a few
words fit for copy and pasting to the RFC.

/Tim

I had a quick look to that PoC and it's basically just a quick wrapper
that depends on GLOB_ALTDIRFUNC. Unfortunately that's a non standard
extension that might be missing on some platform (e.g. alpine won't
probably work because from a quick look the musl libc doesn't seeem to
implement it - https://git.musl-libc.org/cgit/musl/tree/include/glob.h ).
The code obviously needs more work and we will need bunch of tests for
this. Well obviously it's just a PoC but what I want to say is that
implementation is really main thing here and should also help to provide
more details in RFC. For example it's not currently clear that you would
change underlaying glob implementation on some platforms - quite important
thing to mention though. To be honest if there is a good implementation, I
think it's quite unlikely that the RFC will fail.

Hi Jakub. Indeed, it looks like Alpine users would not benefit from this. I
made notes of this in the RFC, thank you.

I understand you would have wanted to see the final PR. I do too. I will
not be involved in producing the final PR and these were the conditions I
agreed on. It's hard to find someone who will invest the time not knowing
if all their work will carry through. I wish there were two steps in the
RFC process. One voting for qualifying the idea/concept, and a second part
to vote for the final PR. The first qualifying part could sort out the vast
undesired ideas. And the second could attract coders and maybe allow for
several PR proposals. Do the php team have any future intentions to maybe
implement an RFC management system that could optimize both the creation,
user experience, and voting process?