That’s definitely not what I was thinking. Rather than wrap the current protocol, or introduce an XML parser, just map Memcached commands to HTTP 1.1 equivalents, and extend (ala WebDAV) for commands with no counterpart:

<http://tools.ietf.org/html/rfc2616#section-5.1.1>

Metadata about a cached item can be encoded using HTTP headers.

Randy


On Jul 8, 2007, at 5:48 AM, Jure Petrovic wrote:


On Sun, 2007-07-08 at 02:23 -0700, Steve Grimm wrote:
Other people brought up HTTP; I was just responding to that. HTTP does
have
certain advantages, such as that it has very mature client libraries
for
just about every language ever invented.

XML would IMO be an awful choice; I think HTTP would be slower to
parse than
memcached's current protocol or a binary one, but XML would be a
performance
nightmare, especially if the parser had to fully support stuff like
entities. Plus you'd throw human readability out the window for
requests of
any reasonable complexity. And you'd be gaining very little from it
anyway;
you'd still have to write custom client libraries since as far as I
know
there isn't really a standard for using XML as the underlying request
format
when talking to a server (XML as the body of an HTTP request, sure,
but
you'd be talking XML *instead of* the HTTP request.)

If I'm wrong, please enlighten me. I can see the benefits of
supporting HTTP
but I'm at a loss as to why you'd use XML at such a low level.

-Steve


To be honest, I like the binary protocol idea. It would be a great
addition to the current protocol, which is IMO enough human- readable and
very efficient for the given task.

But, as there was an interesting discussion about HTTP, I jumped in :)

If I get this correctly, the idea is to wrap the current memcache
protocol with the HTTP. The http body would still have to be parsed
(current parser), which will introduce some latency. However, we get the
authorization and encryption (https) capabilities as part of the
HTTP.

I just mentioned XML because that would give the http body the organized structure, that would allow easy addition of commands and arguments and
could be parsed with libxml2 or something similar. But that still
doesn't mean, that I am convinced that all this (http) is really
neccessary...

Regards,
Jure



Reply via email to