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
