RE: [PHP-DEV] [VOTE] Add is_cacheable() stream-wrapper operation
| From: | François Laupretre | Date: | Mon, 02 Feb 2015 17:31:11 +0000 |
| Subject: | RE: [PHP-DEV] [VOTE] Add is_cacheable() stream-wrapper operation | ||
| References: | 1 2 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-81620@lists.php.net to get a copy of this message | ||
> De : Rasmus Lerdorf [mailto:rasmus@lerdorf.com]
> Doesn't this imply that "path" is the one true cache key? There are some
> issues with that which we will have to address at some point. For
> example, when running fpm chrooted you need more than the path. We'll
> likely need a more APC-like option here to use the device+inode for the
> key. It seems like a generic mechanism like you are proposing needs to
> take this into account and provide some mechanism that tells the opcode
> cache how to determine uniqueness. Perhaps that is simply encoded into
> the path parameter, but then maybe it should have a more appropriate
> name.
Yes, it implies that the path is the cache key. It implies that the stream
wrapper has a way to build unique and reproducible paths (PHK, for instance,
builds a unique ID from (dev/inode/mtime) when opening a package and builds
its paths from this ID).
My first idea was to add a 'cache_key' element in the stream_stat() result.
This element would be a binary string to use as key. This way, the stream
wrapper can return a path, a dev/inode/mtime concatenation, etc. If we don't
want to modify the stat() result, we can define a 'cache_key' hook in
php_stream_wrapper_ops.
I reverted to a system where path is considered as unique because I thought
my original idea would be considered as too complex. And using the path as
key was enough for phar and phk. But I agree, it is not a good solution for
'file:', which should be cached by dev/inode/mtime.
I put the vote in standby.
Cheers
François