On Nov 13, 2007, at 10:49 , Tomash Brechko wrote:
On Tue, Nov 13, 2007 at 10:33:41 -0800, Dustin Sallings wrote:
It is what allowed us to do partially-non-responsive commands
Dustin, seriously, there seems to be the loop in your reasoning that
no logic would break. And no, I'm not concerned with extra bytes, but
Mark from Facebook seem to be, so you should convince him first, I
only did the computations.
He was in the room when we worked out the original packet formats.
Please allow whomever has objections in light of your new data to
raise them on their own.
And please don't be picky on the tone: we all people, and it's nothing
wrong to be angry at times.
I'm not angry, and I didn't think that you were. I'm just trying to
communicate that we seem to have different perspectives on criticality
of an issue.
From my perspective, there are a lot of clients that are working fine
with the protocol as it exists today, but you have a hypothetical
client that can't exist with the text protocol because you don't want
your client to do a comparison on each response to deal with sparse
responses as they're implemented today.
Alternative: Don't use the text protocol. You own the opaque in the
binary protocol, so it does exactly what you were advocating. You can
basically do the following (pseudo-javaish):
int start_seq=arbitrary_number();
Object[] values=new Object[keys.length];
for(int i=0; i<keys.length; i++) {
send_getq(keys[i], start_seq+i);
}
send_noop(start_seq+keys.length);
Response r=read_response();
while(!r.is_noop) {
values[r.opaque - start_seq]=r.value;
r=read_response();
}
Isn't this what you want?
--
Dustin Sallings
