Multi-Interface Patch

[dormando]

>     Yeah, I suppose I don't actually *need* something like that, but new 
> commands keep coming up.  It'd be good to keep up with what's in a given 
> server.

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

> 
>     I'm thinking something near this (in some kind of weird cthon 
> pseudo-code):
> 
>     char *[] key_map;
>     int start_opaque, i;
> 
>     start_opaque = gen_opaque();
>     i=0;
>     for key in keys:
>         key_map[i++]=key;
> 
>     [make request]
> 
>     for res in responses:
>         char *key = key_map[res.opaque - start_opaque];

Yeah, that's the straightforward easy route I imagine. So:

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

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.

Although, brian; if you can make 'noreply' work, then why doesn't a 
simple opaque work? The results will be out of order either way; but 
with key return you'll have to do a hash mapping to return the keys into 
order, or simply return the keys directly to the application.

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

-Dormando