Hackathon / Multidimensional keys / Wildcard deletes

[Paul Querna]

Steven Grimm wrote:
> 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.

All this says to me is that we should have a single protocol :-)

-Paul