On Feb 13, 2008, at 15:05, dormando wrote:
I'd be up for something like that. Another verb?
'caps', heh. The protocol doesn't (and shouldn't) have a handshake
phase though. Lets be careful to balance between "client connects
and does whatever it wants" vs "client connects, chooses some random
code path based off of the 'caps' response, and quietly breaks".
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.
BTW still disliking the lack of key in the binary protocol (playing
with it on flight). I suspect I am going to have to pack it with
the value to make it work for me. The state issues of tracking key
plus + identifiers are just too much overhead. I found myself very
cranky on the flight about this. Of course it may had to do more
with the guy who sat next to me who really stank... but hey, gotta
take out the travel aggravation somewhere :)
Heh :)
Dustin; how is the key to opaque mapping handled in your client?
It'd be nice if we didn't waste memory packing key values
fundamentally in the C client.
I don't have this as optimal as I could. I just have an integer ->
string map.
It's come up on the list a few times. Some have not been able to
imagine dealing without keys, but it's really as simple as putting
your keys in an array, and reserving the opaque space from the
beginning to one past the end and processing values on the way out,
looking up the key by response opaque - first opaque.
Brian wants the key to always be sent with the response, cutting out
the client opaque. I'm under the impression there're a few
implementations of the binary protocol _with_ the opaque though. So
could we compare notes and see if it's a clincher?
It's especially a good thing with UDP (which has no implementation).
You can pack more responses in fewer packets.
So, presently, on a high level there is already an opaque mapping of
values to what the client wants. This is literally the key=value
mapping. The relation of key values to the application happens
outside of the library, so it's not a bother. If the lib wants to
hide the opaque=key mappingit has to do a lot of internal tracking,
which is slow and awkward in C.
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];
Curious to see how other people are doing it though. There's still
time to change the protocol if there's something fundamentally amiss.
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.
--
Dustin Sallings
