Hackathon / Multidimensional keys / Wildcard deletes

[Steven Grimm]

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