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
