> 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?
