Multi-Interface Patch

[dormando]

Aaron Stone wrote:
> 
> On Feb 13, 2008, at 3:35 PM, Dustin Sallings wrote:
> 
>>
>> 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.
> 
> 
> 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