Extensible command syntax

Tomash Brechko tomash.brechko at gmail.com
Wed Nov 7 13:11:54 UTC 2007


On Tue, Nov 06, 2007 at 12:34:19 -0800, Dustin Sallings wrote:
> 	I think the long-term goal is is to reduce the cost of parsing by  
> means of a binary protocol.  Even there, the idea of adding arbitrary  
> extensibility was shot down as unnecessary overhead.

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.


> 	Most of what you described sounds like HTTP (ranges, arbitrary  
> headers, pre-data checks, etc...).  There has been talk of adding an  
> HTTP front-end to memcached.  I don't think anyone is terribly opposed  
> to the idea if it's clean, but nobody seems to want to write it.

Not exactly.  Ranges were just an example of one of the possible uses,
and HTTP won't allow you to do pre-data checks (one could use some
tricks of course).  Besides, HTTP grammar is more sophisticated, while
I proposed to recognize only a fixed (for a given version) set of
keywords.


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.

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


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


-- 
   Tomash Brechko


More information about the memcached mailing list