Extensible command syntax

[Dustin Sallings]

On Nov 7, 2007, at 5:11 , Tomash Brechko wrote:

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

	Your proposal is incompatible with the binary protocol.  Today, they  
run on different ports.

	I don't see how you could go from a fixed format to an extensible one  
without imposing overhead.  There's been a lot of work that has gone  
into the text protocol parser to squeeze speed out of it because it's  
actually burning up too much CPU time.  I believe this is why the MT  
version of memcached came into existence.  Some people get really  
picky about slowing things down.

	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.

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

	See RFC 2616 section 8.2.3 (and 14.20) to see how to do pre-data  
checks in HTTP.

-- 
Dustin Sallings