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.
-Steve
