> What was the reason to *break* the protocol then? Couldn't memcached > just ignore the expiration time here? What happens now is: a client > sends "delete key 0 noreply". Server answers "ERROR", but the client > doesn't expect the reply (because of "noreply"). The client then > sends some other command, say "set bla-bla", now reads "ERROR", then > sends "get bla-bla", reads "STORED", etc. I.e. all replies are > "shifted" because of that unexpected extra "ERROR". What was the > point of that? > > The commit in question is 5da8dbab2a815c00617ab60b641391ada8d96f40. > Can it be fixed?
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! -Dormando
