Hackathon / Multidimensional keys / Wildcard deletes

[Jure Petrovic]

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