> De : Rasmus Lerdorf [mailto:ras...@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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
