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
