Extensible command syntax
dustin at spy.net
Wed Nov 7 19:53:36 UTC 2007
On Nov 7, 2007, at 11:29 , Tomash Brechko wrote:
>> What are your goals, out of curiosity? For review it'd be helpful to
>> know problems which are not solvable using the present protocol.
> My short term goal is to implement new commands with extensible
> param[=val] syntax. Then for update commands I'll add 'noreply'
> boolean option (which will be truly optional, that's the point), and
> will set it if user aren't going to use the reply anyway, for instance
> when Perl binding is called in void context (wantarray returns undef).
> Perhaps this will speed up things a bit. The idea is not mine
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.
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.
Are you concerned about doing a large number of updates in a batch?
Are you sure you can't handle this on the client side? Pipelining
makes the responses become almost a non-issue.
> On Wed, Nov 07, 2007 at 10:16:00 -0800, Dustin Sallings wrote:
>> Your proposal is incompatible with the binary protocol. Today, they
>> run on different ports.
> I only showed that binary and text protocols could co-exist. Pity if
> it was already made by incompatible means.
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 don't see how you could go from a fixed format to an extensible
>> one without imposing overhead.
> Of course there will be few more instructions, I don't count that as a
> significant overhead. If we talk about extensible binary protocol,
> recall how UTF-8 works: you have to process as many bytes as required
> to encode the data, no more. So additional parameters could be
> chained in the similar way. For text param[=val], you have to process
> as much pairs as are there, and it's user's responsibility to give as
> little of them as required.
This makes sense in abstract, but I'm failing to see the deficiency
you think warrants it.
More information about the memcached