Multi-Interface Patch

[dormando]

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

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

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?

I'm not sure I even see this as something the library should be handling 
itself.

If, as a user, I stuff the keys into a flat array, I could loop over the 
array and pass an "opaque" (array index) in with the request data. Then 
the library interface could be a callback or return an array, doesn't 
matter. It does require special handlers for the binary protocol though :(

Or the library "hides" the opaque process and continues to provide the 
same interface, which requires expensive tracking.

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.

Curious to see how other people are doing it though. There's still time 
to change the protocol if there's something fundamentally amiss.

-Dormando