Hackathon / Multidimensional keys / Wildcard deletes
sgrimm at facebook.com
Sun Jul 8 19:33:57 UTC 2007
Ian Kallen wrote:
> I think protocol flexibility allows clients with simple requirements
> to dumb down for speed and smarten up for new capabilities.
Not that you were necessarily saying this, but I want to point out that
there does not need to be a contradiction between high speed and
extensibility. One could (and should!) design the high-speed protocol in
such a way that it can be extended while still remaining fast.
That said, to the extent that you're introducing semantic changes to the
protocol, there are limits to how much backward compatibility you can
get in the case of new clients talking to old servers. A client that
expects the server to pay attention to some new option is going to
break, possibly in subtle hard-to-debug ways, if the server doesn't know
what the option means. That's independent of whether the option is
specified in such a way that the server can still parse the rest of the
command successfully. However, you should nearly always be able to
support old clients talking to a new server.
I for one would vehemently oppose any proposal that made new features
available only via the low-performance protocol. Both because as a
consumer of the high-speed protocol, I will want to use the new features
too, and because as soon as you do that, you irretrievably place limits
on clients that want to act as a proxy between external clients
(speaking some other protocol) and memcached. They are stuck either not
offering the advanced features or offering all the features with bad
performance, neither of which is a good situation. Or worse, I suppose,
they're stuck using one protocol for some operations and another
protocol for other operations.
More information about the memcached