On Sun, 2007-07-08 at 08:48 -0700, ydnar wrote: > 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
Ok, now I see what you mean. Thanks :) >In general, I disagree -- I don't like having multiple protocol >interfaces to one thing like memcached -- all it means is various >clients will only implement one of X possible protocol formats, all >with different feature sets, creating a massive mess on the client side >of memcached, something that isn't often discussed here. Additionally, there could be compatibility problems. Upgrading server will neccessary require the upgrade of client libraries. >I think there is a more interesting thought that this is leading to -- >that memcached should be more modular. In the last couple weeks people >have brought up having multiple backend storage methods. Perhaps we >should look at making a *compile* time selection system for both a >frontend command parser and a backend storage system? Good idea. But does that have to be a compile time decision? What about people that use binaries? Wouldn't loadable modules be better design decision? Regards, jure
