Hackathon / Multidimensional keys / Wildcard deletes

[ydnar]

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
>
>