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
