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!
