Hi,
I've started this discussion, but did not participate (cause I was ill).
I like the glob:// implementation, it solves my problems as developer.
Another problem with implementing glob like behavior in each stream
implementation is that it breaks compatibility, potentially even causing
security problems.
Example:
$filename = basename($_FILES['userfile']['name']);
$zip = new ZipArchive();
$zip->open('my.zip', ZIPARCHIVE::CREATE);
$zip->addFile($_FILES['userfile']['tmp_name'], $filename);
$zip->close();
readfile("zip://my.zip/$filename");
This would give an unexpected result if the filename would be "is this
ok?.doc"
In the future perhaps it would be nice to specify the streams like
subversion does, eg: 'zip+glob://mydir/*.jpg'. Than the following might
also be possible: 'ftp+zip://...'. However for now, this is beyond the
scope of php stream and therefore I'm extremely happy with the glob
implementation as provided by Marcus.
Best regards,
Arnold
LAUPRETRE François (P) wrote:
From: Pierre [mailto:[EMAIL PROTECTED]
It is not about taste. A glob is not a URI-like data. It is a
filter. I hope you understand my point now (for better glob
support but no glob://), let see what the other developers
think about that.
I agree. PHP glob() needs to be rewritten to call a glob() hook in stream
wrappers. And only the 'plain file' wrapper would then call the OS native
glob(). Other stream wrappers like zip:, phar:, or phk: would provide their own
implementations (provided they can use a reliable fnmatch()).
I will take another way to understand why one can add URI wrappers in the core
stream
implementation without discussing it and even worst, without allowing any discussion about
his choice.
Agree again.
François
