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
