fig-standards
fig-standards copied to clipboard
php-fig
Allow colon (`:`) in cache key
Redis recommends to use colon to namespace ours keys, and many tools use this pattern to analyse keys. So we loose much power by forbinding this.
More information there : https://github.com/symfony/symfony/issues/45599
This is not a trivial change, so it requires either an Errata vote or a replacement PSR . @Crell, as Maintainer of PSR-6, what is your opinion?
Tried to identify the discussion or at least conclusion about the benefits/drawbacks of how those specific character ended up as reserved. From the top of my head, I can't think why not allowing some characters will be beneficial. I just want to understand and learn here. Tried to find in the git commit history, in the PR discussion (https://github.com/php-fig/fig-standards/pull/149) or on the mailing list here: https://groups.google.com/g/php-fig/ but didn't managed to find a reasonable mention.
This is not a trivial change, so it requires either an Errata vote or a replacement PSR . @Crell, as Maintainer of PSR-6, what is your opinion?
While we're doing this for Redis we should also look at other common caching platforms we can support, plus do the same for PSR-16 in one go.
This is not a trivial change, so it requires either an Errata vote or a replacement PSR . @Crell, as Maintainer of PSR-6, what is your opinion?
Correct. If any implementing library doesn't support it, it would be a BC for them. Surveying the most famous implementation and checking for this would help pushing this errata forward.
While we're doing this for Redis we should also look at other common caching platforms we can support, plus do the same for PSR-16 in one go.
Good idea. Pinging @dragoonis as the editor.
We deliberately excluded those characters because we expected them to be the most likely to be used in future PSRs extending PSR6, such as a namespacing PSR or a cache-tags PSR. So you could end up with a cache key like foo:bar:baz@beep@boop, which would mean a cache key with a 3 part namespace and cache tags beep and boop. Those extensions never materialized, but they potentially still could. We did not look into what specific cache backends recommended for features at the time, just reserved the stuff that seemed likely to mean something.
PSR-16 followed suit for compatibility, I presume.
As @vdelau noted, this is a substantive change so cannot be made in the spec itself; period. If anything, it would be an errata, or maybe a small extension PSR as discussed above. (Or maybe such a spec extension could make sense as a PER? I'm not sure there.)
Are there similar patterns in other cache backends? IMO, if we're going to do it we should do it right, which means formally adopting : as a namespace separator, assuming that is applicable across sufficient cache implementations.
Or maybe such a spec extension could make sense as a PER?
I don't know what is the best way to handle this issue. You have more experience with FIG/PSR than me, so I let you drive this change.
Are there similar patterns in other cache backends? I
I don't know, I use only redis and FS for caching data.
@lyrixx @WyriHaximus @Jean85
PSR-6 - larry is handling it, and what he said aligns with what was happening, when we built PSR-6, so nothing from me on that one.
PSR-16 - I'm happy for the FIG committee to proceed with removing ":" as a reserved character on PSR-16, or documenting that we accept ":" to make it obvious to users of that standard. If a member of the committee could make a Pull Request (for the .md and the .php file), I can review and approve that PR.
If you do ever ping me on GitHub or Mailing List, then please also DM me on twitter, or other social platforms to get my attention to look at specific PSR's discussions/threads.
Thanks for reaching out @lyrixx
Waiting for someone to do the research on this. I don't have the bandwidth to do so:
Are there similar patterns in other cache backends? IMO, if we're going to do it we should do it right, which means formally adopting : as a namespace separator, assuming that is applicable across sufficient cache implementations.
This was never followed up on, and changing the spec in-place is not an option anyway, so closing.