binary protocol motivations

[Dustin Sallings]

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