Extensible command syntax

[Tomash Brechko]

Hello,

I'm new to this list, I'm sorry if the following was already discussed
here.  In that case please point me to the right thread in the mail
archive.


I see that in SVN version of memcached there are protocol extensions
that are not found in memcached 1.2.2.  Among others there is a
support for so-called "cas" value.  The syntax for modifying commands
was extended,

  <command name> <key> <flags> <exptime> <bytes> [<cas unqiue>]\r\n

and there's also new "gets" command.  If I got it right, <cas unqiue>
should be specified for "cas" command, and should be omitted
otherwise.

I think this route would lead to extensibility problems later.
Suppose we decide to add yet another field, "cas2".  Existing commands
aren't aware of it, so we have to introduce yet another command, say
"cas2", hence the syntax would be

  cas2 <key> <flags> <exptime> <bytes> <cas2 unqiue>\r\n

But what if "cas" and "cas2" are orthogonal, and sometimes we want to
use both?  Wouldn't we then also have to declare "cas12",

  cas12 <key> <flags> <exptime> <bytes> <cas unqiue> <cas2 unqiue>\r\n

?  Actually, the problem is already there, for instance you can't use
"cas" value with, say, "replace" command.

Perhaps memcached should come to a better syntax that extends
linearly, not exponentially.  Such syntax might be

  nset [<opt_name>[=<opt_value>]]+\r\n

("nset" name is arbitrary, [...]+ denotes one or many), and instead of
introducing "cas" command and "cas" positional value for it, we would
then introduce an option, cas=<value>.  Current positional arguments
<key> and <bytes> will become mandatory options with the same names
(i.e. key=<key> bytes=<bytes>, <flags> and <exptime> will be
optional).  Other modifying commands might be introduced ("nadd",
"nreplace", etc.), or better to have a single "nset" command with an
option mode=replace etc.

Likewise, "nget" might be introduced,

  nget (key=<key> [<opt_name>=<opt_value>]*)+\r\n

where all options correspond to the key=<key> they follow.


This change will open the way to new extensions, like

  # Get 100-109 byte range.
  nget key=some_key offset=100 length=10\r\n

  # "check" boolean option means to ask the server first if it is
  # going to accept the data.  If it rejects early (key exists, key
  # was deleted with not-yet-expired timeout, server can't allocate
  # storage), there would be no need to send the data.
  nset mode=add check key=other_key size=100\r\n
  -- wait server reply, if positive do send:
  <data block>\r\n

etc.


What do you think about this proposal?


-- 
   Tomash Brechko