On Thu, Jul 29, 2010 at 6:54 AM, j.s. mammen <mamm...@gmail.com> wrote:
> Folks, lets not get bogged down by REST defined by Roy Fielding in > 2000. > > My question was simple. > Here it is again, rephrased. > > Do we need to implement a memcached layer whereby we can access the > cached objects by using HTTP protocol. Here is an example of getting a > cached object from a server > GET [server]/mc/object/id1 > I'm finding this an interesting discussion because at work we have a number of custom back-end services that all require custom clients wherever they are used. In some ways they are similar to memcached where each server needs a client and all the servers that use the client need to be configured the same. The server-side of these services tend to be pretty simple just serving requests, and the client code often makes some decision about which back-end server to use from a list of configured servers (mostly for HA, though). The problem I see with our set up is that all the clients must be managed on every machine that needs to talk to a back end service. And because of the binary protocol any changes to the request (e.g. adding a new parameter) requires that the clients get recompiled and pushed out to every machine. Leaves room for breakage. Our existing clients are really bad at returning any useful error messages, which http responses can do easily. I've been pushing to move to a http protocol and get rid of the custom clients. We have load balancers that are really good at http so we could use those in front of a few machines so the client code is just used in those few places -- thus, easier to manage. In some cases we could have we clients use these services directly if it we used http instead of using our web serves as proxies. Now, the same discussion has happened at work about the binary protocol being much more efficient. Indeed, that's true, but in some cases that overhead is not that significant compared to the overall request. It may add up, sure, but how critical that is depends on our needs - you don't here much talk of moving http to a binary protocol, after all (although I'm sure Google and Yahoo think about keeping their request and response headers as small as possible). Anyway, specific to this thread, would there be any reason memcached would need to talk http? Isn't that something that a pretty simple wrapper could add to your favorite memcached client? Certainly doesn't seem like something memcached would need to support natively. It's up to the end-user to determine if the http overhead is significant or not, no? -- Bill Moseley mose...@hank.org
