run_command() Perl binding

[Timo Ewalds]

Tomash Brechko wrote:
> In current text protocol there's no way to know the size of the reply,
> and command replies vary.  Once run_command() is a generic interface,
> it should be possible to call it for any command.  But
>
>   run_command("get foo\r\n");
>
> may contain _any_ character sequence in the reply, including "END" and
> friends.  And if run_command() will be made aware of the protocol
> details, it won't be generic and forward compatible any longer.  In
> other words, it's impossible to write a transparent proxy with current
> protocol.
>
> Given that it's broken anyway, shouldn't we deprecate it, and remove
> in the future?
>   

I wrote a memcache proxy a while ago, and you're right, it does need to 
understand the protocol. It really wasn't that hard to write though, 
since the protocol is so simple. I wrote it in php in a day as a proof 
of concept, event based, complete with connection sharing and request 
pipelining, and possibly request combining (ie several gets combined to 
one multi-get). I think it may even have done the hashing itself, so 
from the clients perspective, we'd just have one memcached server. 
Despite being only a proof of concept, written in php and needing to 
know the protocol, it turned out to be surprisingly fast. If we ever get 
to the point that we need too many persistent connections for memcached 
to handle, and for some reason we reject the udp protocol, I wouldn't 
hesitate to revive that project, and possibly even put the php version 
live for a couple days/weeks while we rewrite it in C (ie so we can use 
epoll instead of select, can do fewer memory copies, faster, etc).

Timo