Multi-Interface Patch
dormando
dormando at rydia.net
Wed Feb 13 23:59:20 UTC 2008
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
More information about the memcached
mailing list