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
