Yeah, my main complaint about the original 'noreply' code is that the error handling was completely FUBAR. I'm sure someone somewhere will want a noreply command that never gives them errors, but that's really really broken.
+1 to having it crap back errors. -Dormando On Mon, 26 Jan 2009, Toru Maesaka wrote: > > > In the binary protocol, we can get both the efficiency gains of > > sending commands that are likely to be successful, and still be able > > to handle specific failure cases due to having opaques that can map > > back to the requests. > > True. It definitely sounds wasteful to not take advantage of this. > > > Separate in what way? setq vs. setqq? > > Heh, I was trying to think of ways to provide the behavior as we know > from the ascii protocol and a case that can return an error but you've > made it clear that there is no need to do this in your reply, thanks. > > So, time to update the binary protocol? where's dormando ;) > > Cheers, > Toru > > > On Mon, Jan 26, 2009 at 3:52 PM, Dustin <[email protected]> wrote: > > > > > > On Jan 25, 10:13 pm, Toru Maesaka <[email protected]> wrote: > > > >> I personally think that the behavior of not responding at all is okay > >> since this is for complementing the no-reply > > > > I never particularly liked the no-reply mode for roughly the same > > reason. I think specifically supressing any status, even the rare > > failure will lead to hard-to-debug situations. > > > > It was unavoidable in the text protocol because there was no way to > > indicate which of several pipelined no-reply commands failed. > > > > In the binary protocol, we can get both the efficiency gains of > > sending commands that are likely to be successful, and still be able > > to handle specific failure cases due to having opaques that can map > > back to the requests. > > > >> Here's a thought, could we separate the set commands? > > > > Separate in what way? setq vs. setqq? >
