Multi-Interface Patch

[dormando]

Timo Ewalds wrote:
> 
> 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

You're absolutely right that it can be made to be negligible. I guess my
main reservation is the extra "standard" client logic to get it right.
Then you're stuck making tradeoffs or assumptions about the protocol in
order to optimize the check.

Tho as stated it's totally not a big deal. Lets not worry about it for
now :)

-Dormando