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 ;).
