Multi-Interface Patch

[Dustin Sallings]

On Feb 13, 2008, at 16:11, dormando wrote:

> See my response to aaron. I'm actually okay with a 'caps' command,  
> but there're caveats :\

	I need to figure out how to communicate how much/little I care about  
stuff better.  This is really low on my list.

> - If this is _within_ the library, it's assuming all of the keys  
> have been passed in as a list already. It also requires a memory  
> allocation or buffer just for the mapping (which might not be so bad  
> on its own if kept persistent).
> - If this is _outside_ of the library, it's even easier, since you  
> can map the opaque almost directly into the original data structure.

	I don't expose it outside of my client.  It feels to me like things  
that should be done for you.

	There was an argument that performance can be better if clients can  
receive values as they come.  I don't think this actually has any  
effect on that.  The client still has to *read* the data and at least  
provide abstractions for unpacking it.

> It looks like brian's trying to map the opaque from _within_  
> libmemcached. Since it has callback interfaces, it doesn't  
> necessarily understand how to map everything back, or what the  
> counts are.

	It is a difference in protocol, but I basically do the same thing.   
Regardless of protocol, I call this at the high level:

	public void gotData(String k, int flags, byte[] data) {
		// do stuff
	}

	In one case, I have to pull it out of the result stream, and in the  
other, I've already got it and just need to match it.

>>    I won't argue with that point, but I'm *really* interesting in  
>> tagging my client as a 2.0 release and retiring in the mountains  
>> somewhere.
>
> The great mountain half pipe? :)

	I really thought I broke my neck and pelvis on Sunday.  As I'm  
walking today, I'm going to be sure to not make whatever mistake that  
was again this weekend.  :)

-- 
Dustin Sallings