On 11/23/2016 10:57 PM, Jordi Boggiano wrote:
I understand where "MUST treat an item as expired once its Expiration
Time is reached" comes from, and I would agree, but for a cache it makes
little sense to be so strict and adamant about it. An entry that has a
TTL of 30 seconds is probably going to be fine at 31s too, especially if
expiration can't be expressed as a point in time.
Relaxing that would allow implementations to conform to the PSR-6
interface and adding stampede protection the same way apc(u) / squid do,
i.e. returning a slightly stale item while a single process is updating
the cache.
>
> Not a deal-breaker, but "SHOULD treat an item as expired" can be
> implemented as "always treat..." if anyone so desires, whereas the
> opposite is not possible.
I am a believer in pragmatism and given that I'd say an implementation
that does this even if it violates the spec is totally fine as long as
the user chooses it willingly and they know what it means then
whatever. I don't think SHOULD or MUST will change a whole lot in
practice there, but I also don't really have anything against changing
it.. Anyone else got something to add?
We discussed the "grace period/stampede problem" at length for PSR-6.
The end conclusion was that an implementation that wants to and is able
to can make a grace period before expiration rather than after; viz,
auto-regenerate a value the first time it's requested in the 5 min
before it's expiration time rather than the 5 min after it's expiration
time. The net effect is the same. The expiration time is a hard limit,
by design. "After this timestamp, DO NOT WANT!"
I believe PSR-6 should mimic that behavior for compatibility purposes,
so would be against changing the MUST to SHOULD.
Alternatively, I'd suggest adding something like
CacheInterface::setDefaultTTL() and CacheInterface::TTL_NEVER = -1, with
support for the latter being subject to the actual storage capabilities.
I am rather against setDefaultTTL because that'd mean every lib and
user has to constantly reset the default TTL to make sure they have
the right one set, so you might as well just set the TTL you want.
Agreed. Setting the configuration on a cache pool (which PSR-16 is as
well, effectively) is out of scope for the spec.
TTL_NEVER however sounds like a good addition, I'd be curious to hear
other people on this.
Cheers
We discussed this at phpworld. Michael, do you have the notes of that
conversation and what the outcome was? My general recollection was a
consensus around "be consistent with PSR-6 to avoid ugly and confusing
bugs", but I don't recall the exact conclusion on TTL-never.
--Larry Garfield
--
You received this message because you are subscribed to the Google Groups "PHP
Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to php-fig+unsubscr...@googlegroups.com.
To post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/php-fig/1e30093f-2f33-216d-919d-5b4a8d0789e7%40garfieldtech.com.
For more options, visit https://groups.google.com/d/optout.
