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

[Nicolás Lichtmaier]

>> Having the expiry time returned explicitly instead of part of the data
>> does make things slightly easier, but otherwise isn't much of an advantage.
>>     
> I was advocating that point actually ;) What I'm curious about was
> Dustin's idea of having a stream of expiration data that a service could
> subscribe to.
>   

I guess the utility is to be able to have consistent L2 caches. So that 
an L2 cache would be able to drop its value if somebody has 
incremented/deleted/etc it. My "send the remaining TTL" patch only 
handles the expration case, having some kind of notification would 
handle every case.

A needs "key1", gets it from memcached, caches it locally. Register for 
key1's modifications.
A needs "key1", it's locally cached, no memcached access.
B increments "key1", invalidation notifications get sent. A invalidates 
its local cache.
A needs "key1", gets the new value from memcached.

I don't know how useful this would be, but I think this is what is being 
talked about, I think.... =)

Bye!