run_command() Perl binding

[Tomash Brechko]

On Fri, Nov 09, 2007 at 15:31:21 +0300, Tomash Brechko wrote:
> It turned out that run_command() binding is broken, so there's no
> support for 'noreply' through this call: I think it wouldn't be
> right to add a feature to a broken code (not to say that I tried and
> failed ;)).  I added FIXME entries to this function, so you may see
> for yourself what's wrong there.  I plan to fix this later.

Ooops, can't fix that :-(.

Here's the original code:

  # returns array of lines, or () on failure.
  sub run_command {
      my Cache::Memcached $self = shift;
      my ($sock, $cmd) = @_;
      return () unless $sock;
      my $ret;
      my $line = $cmd;
      while (my $res = _write_and_read($self, $sock, $line)) {
          undef $line;
          $ret .= $res;
          last if $ret =~ /(?:OK|END|ERROR)\r\n$/;
      }
      chop $ret; chop $ret;
      return map { "$_\r\n" } split(/\r\n/, $ret);
  }


As you can see, end-of-reply condition is wrong: there's also DELETED,
EXISTS, CLIENT_ERROR ..., VERSION ..., etc.  But will it work if we
add those to the set?

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?


-- 
   Tomash Brechko