Extensible command syntax

[Tomash Brechko]

On Wed, Nov 07, 2007 at 10:09:59 -0800, dormando wrote:
> The semantics of the protocols will be different?

No.  I will not change current text protocol.  I will just add several
new commands, and will parse them differently.  Any existing code
won't be affected.


> 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
actually.


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.


> 	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.


> 	Then there are the client authors.  There are many memcached clients 
> out there today that are working pretty happily.  A change in the  
> legacy protocol could be painful.

As I said above, I'm not going to change the existing protocol, I will
only add new commands with new syntax.  Client authors will be free to
switch to them, or to use legacy protocol, or to use binary protocol.


-- 
   Tomash Brechko