kroki wrote:
On Oct 29, 1:10 pm, dormando <[email protected]> wrote:
The reason was that nobody was using that extra parameter and the
developers wanted to remove it. Also, despite having *a year's*
worth of releases and prodding on the mailing list for client authors to
test, this is the first time it's come up.
We already have issue #3 filed to adjust this :P It's ancient but we were
already planning on adjusting it for the next release. I'd suggest you
look at the issue at code.google.com/p/memcached and see if the ideas are
on track? That'd be a big help!
I don't see how fix for issue#3 helps. The test case even expects
that bogus "ERROR" (see
http://github.com/dustin/memcached/blob/f1c6f07044056f09c1f960d226588a5dd5521e2e/t/issue_3.t#L19).
I'm not telling that expiration should work. I only say that "delete
key NUM" and "delete key NUM noreply" should be a valid syntax. This
is because:
- there exist more clients than memcached developers are aware of
(many sites implement their own lightweight versions).
- not every client author constantly monitors the list and is ready
to invest the time to update the client every time memcached developer
comes with the idea of what will be better for everyone.
- not every installation uses latest version of memcached, so
existing clients have to be compatible with both old and new server
versions.
There was no technical reasons to break backward compatibility, and it
should be easy to restore it ;).
There is, because delayed delete was a bit special.. it would pin the
object in memory until the expiry time ran out making add / replace /
incr / delete fail.. By just ignoring the number we would break the
logic the clients expected.. I think it is a lot better that the server
sends back an error message and let the client handle that instead.
I would also find it extremely hard to believe that people will go from
memcached 1.2.x to 1.4.x without testing that the clients they use still
work with the server (and deferred deletes is still available in 1.2.8).
Cheers,
Trond
