Extensible command syntax

Tomash Brechko tomash.brechko at gmail.com
Wed Nov 7 21:18:16 UTC 2007

On Wed, Nov 07, 2007 at 11:53:36 -0800, Dustin Sallings wrote:
> 	I don't feel that this answers the question.  How are the current  
> commands insufficient for your needs?  They seem to work pretty well  
> for most people.

But could you please first explain how current commands can solve
Brian's problem?  As you recall, he said that with mandatory
positional parameters he can't omit expiration time nor flags while
doing update.  You correctly answered that CAS case is a no issue, but
what about other updates?

The fundamental flaw with positional parameters is that you can
neither add nor even omit anything.  I'm sure you realize this
yourself, and the addition of CAS clearly shows it: the scheme is
fixed, so let's add another two or more commands with another fixed
set of parameters.  What if I want to use CAS will all update
commands, not "set-with-cas" only?  For Brian's case, it's possible to
say, "let's introduce some special exptime value, which would mean 'do
not change'", and the problem will be fixed, really.

To my mind, the whole protocol is broken, I think it was never
thoroughly designed, rather fixed here and there over time.  This is
called "patchy design", as I was told.  For instance, 'get key key
key...'  returns nothing for found keys that weren't found, while it
could return NOT_FOUND.  This alone breaks all pipelining, because
there's no direct correspondence between requests and replies, and
instead of simply counting the results one has to _compare strings_ to
know which result goes where.  We may as well put aside all talks
about performance bit-tweaking until all such flaws are fixed.
Sending a potentially large chunk of data just to learn that the key
is locked now, sorry, is another example.  I also have my doubt about
"flags" field.  Since they are opaque, couldn't you use some byte
range of the data itself?

I do understand your worry, every significant change is painful,
especially when you have lots of derived work.  But this particular
change actually doesn't break much.  Now, instead of adding another

  } else if (strcmp("newcmd", ...

you add it elsewhere, and that's all.  It won't close any door, but it
will open many more.  And it will be the same O(1), just for smaller
values of 1 :).

> 	I'm a bit dubious of the performance benefits of not responding in  
> general.  We have the same sort of thing in the binary protocol for  
> doing bulk fetches, but there has to be something to tell you when  
> you're completely done.  I don't see that you could process another  
> command afterwards without it.

When you add data to the cache, you can't do anything with the
response anyway.  Success?--Good.  Failure?---The data wasn't cached,
maybe will have luck next time.

For replace, if the server invalidates the old data even if it can't
store the new data (and I was told that this is the case, haven't
looked myself yet), there's also no need in reply: once we invalidated
the old data, we are basically in the "add" case, as described above.

But you know, I'm not sure myself.  Let me try it, and maybe I'll be
ably to show you some nice charts :).

> 	Others have brought up running different protocols on the same port. 
> It's somewhat possible (would require increasing the complexity of the  
> code somewhat), but I don't much see the point.  A client shouldn't be  
> expected to discover what protocol a server speaks, so I'd expect  
> you'd have to configure it at least somewhat.

I was putting it the other way around.  Client may speak only one
protocol, text or binary.  And server upon reading the request can
easily distinguish the two: is first byte a zero?  If yes---binary,

> 	This makes sense in abstract, but I'm failing to see the deficiency  
> you think warrants it.

Please be more open-minded.  I don't yet know who's'who on the list, I
learned about memcached only a week ago, but you sound like you may
set no-go to my patches.  And I'm not going to push on you anyways ;).
I'll continue to post patches unless someone would object, but it's up
to you to decide if this is a no issue, or there are some problems
with current protocol indeed.

   Tomash Brechko

More information about the memcached mailing list