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
