Hi,
Le 20/06/2017 à 18:35, 江湖大虾仁 a écrit :
Hi François,
Good work, but I'm not sure if I missed something because I didn't
find any discuss relating to this RFC in my mail box, as well as the
PR on GitHub. I have a question about the detail of `cache_key`:
Discussion : http://www.serverphorums.com/read.php?7,1505444
> If the method is not defined, every path associated to this wrapper
are non-cacheable. In order to avoid key value conflicts, the returned
key must start with the same '<scheme>://' prefix as the input path.
If it not the case, an error is raised and the key is ignored.
Why don't we simply ask `cache_key` to provide the path, and we
combine it with scheme in the core? It's much easier for userland to
implement this feature since there is less limits, and we didn't need
to worry about the key conflicts between different stream-wrappers any
more.
1. The userspace code needs to get the full URL as input, as a stream
wrapper may be associated with more than one scheme.
2. In the most usual case where the input URL is to be used as key, I
cannot ask developers to compute the returned path by removing the
'<scheme>://' prefix from the input URL. The API is much easier to
understand if they just return the input URL. It is also faster in this
case because the PHP function/method returning its input argument won't
even duplicate the data (it will just increment the zend_string
reference count).
Regards
François
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
