Extensible command syntax
dormando at rydia.net
Tue Nov 6 20:43:31 UTC 2007
Proof of concept, I think. He said it was based off of libevent's http
Honestly I'd rather make perlbal/etc speak memcached on one end than
make memcached speak http to another, but that's just me? :)
Chris Goffinet wrote:
> Didn't Paul say he had some parts of it written?
> 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
More information about the memcached