I answered this more thoroughly when Nicolas showed up in IRC, so in
summary:
- This patch has the same issue the cas patches did. It's writing the
data to an extra shared buffer that'll get overwritten. I'm also not
convinced it'll work all that well; being confused with CAS values/etc.
- We discussed the alternative method of wrapping the real expiration
time inside your serialized object, and using that instead. We think
that works out better for all invovled :)
-Dormando
Nicolás Lichtmaier wrote:
If somebody wants to use memcached as a 2nd level cache, and put a local
memory cache before, there's a problem with expirations. There's
currently no way to know for how long a given value can be locally
cached. So, in order to implement some local caching before memcached,
and to properly handle expirations, it would be nice if the remaining
TTL could be sent to the client. So, the client knows "this value is
fresh and can be used for another 3601 seconds". This patch is a sample
implementation, it just adds the remaining ttl to the end of the get's
response. What do you think? Is this feature worthwhile?
Thanks!
PS: The protocol is not very expansible, adding a value there can be
risky. I've tested this with PHP's memcache client library and it seems
to work Ok.
PPS: I'm resending this, somehow the first time it didn't get through, I
hope this time it will =)