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
