On Feb 3, 2015 12:31 AM, "François Laupretre" <franc...@tekwire.net> wrote: > > > 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 am not a big fan of putting this info on the path. A path must remain a path or URI, not some random generated string, requiring to be parsed to get the actual path. A cache key sounds cleaner, easier to implement and valid.
