[PATCH] Sending remaining TTL in "read"'s response

[dormando]

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 =)
>