Extensible command syntax

[dormando]

> Thanks for the insight.  Still, binary and text protocols may happily
> co-exist (for instance, use binary if first received byte is zero,
> text otherwise), each has its own uses.  And extensibility may be
> designed so that it would impose no overhead when not used.

The semantics of the protocols will be different?

> Anyways, my goals can't be achieved within the protocol with
> positional parameters, so I have to work on that anyway.  And more
> flexible syntax might help with Brian Aker's problem.

What are your goals, out of curiosity? For review it'd be helpful to 
know problems which are not solvable using the present protocol.

> In separate mail I'm sending patches with my current changes.  First
> two are bugfixes, and the third one is a small improvement of current
> command parser.  There are no changes in command syntax or semantics,
> the patches are just the ground for future changes.  It would be nice
> if someone would review them, and push to SVN (at least the fixes).

The fixes look reasonable, I suspect someone on the list will test/push 
them shortly. The gperf thing will need to be baked in and reviewed in a 
larger context I think.

Personally I'm not familiar with it at all, so I'd have to understand 
that it doesn't cause an entry barrier for folks on say solaris for 
making changes to the sources. If some cursory peer review doesn't find 
anything awful we could bake it in a branch... I'm just not sold on the 
idea of editing the text protocol yet.

> BTW, is there a way to search the mail archive?

google.com: site: lists.danga.com memcached

Dunno if it's archived elsewhere that's searchable.

-Dormando