Extensible command syntax

[dormando]

Proof of concept, I think. He said it was based off of libevent's http 
service.

Honestly I'd rather make perlbal/etc speak memcached on one end than 
make memcached speak http to another, but that's just me? :)

-Dormando

Chris Goffinet wrote:
> Didn't Paul say he had some parts of it written?
> 
> -Chris
> 
> On Nov 6, 2007, at 12:34 PM, Dustin Sallings wrote:
> 
>>
>> On Nov 6, 2007, at 10:36 , Tomash Brechko wrote:
>>
>>> I think this route would lead to extensibility problems later.
>>> Suppose we decide to add yet another field, "cas2".  Existing commands
>>> aren't aware of it, so we have to introduce yet another command, say
>>> "cas2", hence the syntax would be
>>
>>
>>     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.
>>
>>     In practice, adding commands in binary protocol implementations of 
>> both clients and servers has not been difficult enough to justify any 
>> kind of extensibility within commands in general.
>>
>>     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.
>>
>> -- 
>> Dustin Sallings
>>
>>
>