Multi-Interface Patch

[Timo Ewalds]

dormando wrote:
> Aaron Stone wrote:
>> It'll become a de-facto handshake no matter how hard we try not to 
>> have that happen. Where it makes sense to me is when a client library 
>> is first given a list of servers to know about. It makes a lot of 
>> sense to ask each server what it supports at that time.
>>
>> Of course, losing a server then reconnecting and failing to check 
>> capabilities could lead to problems. Say you try rolling in a new 
>> memcached version, it fails, you roll back, but your clients still 
>> think they're talking to the new code. That'd be ugly.
>>
>> So capabilities would be checked on first connection, and first 
>> connection after a connection loss.
>
> Then every php site running without persistent connections will double 
> their latency and add all of the processing for the capability check 
> for every memcached call :) Yes, we can say "don't freakin' do that" 
> but people tend to do it to deal with broken setups.
>
> Where's the happy middleground? Presently there's a 1:1 mapping 
> between exercizing features and the application interface. We'll only 
> end up requiring a discovery phase if memcached provides automatic 
> protocol upgrades.
>
> -Dormando
>

To know absolutely what the memcached server is capable of, yes, you'd 
need to do the handshake every time, but in practice that shouldn't be 
necessary. The PECL client can keep state between connections, as can 
our pure php implementation, even though we don't use persistent 
connections. We do that by using APC, but the PECL client wouldn't even 
need that. If you have it check only the first time, maybe after a 
timeout (once an hour shouldn't be a big deal), and every time it is 
disconnected by a bad response/command, it would amortize to negligible 
overhead. There is no reason why it couldn't be a config option to 
check, or even a config option to specify the capabilities manually. I'm 
still not sure it's needed, but this isn't a reason to not do it.

Timo