On Aug 8, 11:47 am, Neil Mckee <[email protected]> wrote: > I looked pretty hard at the shim idea back in May, but the engine protocol > is really a different protocol. There was not a 1:1 correspondence with the > standard memcached operations.
Well, all the memcached operations are built on top of it... do you mean specifically multiget might call into the engine multiple times for a single "request"? > If we define a standard sFlow-MEMCACHE measurement then it should be > something that any memcache daemon can export, so it's really tied to the > external spec, and shouldn't reflect anything about the internal structure > of the implementation. > > Instead I went back and tried to minimize the number of source code lines > that would have to be added to memcached.c and thread.c. It's just a > handful now. Pretty minimal. I can understand what you're getting at here, but if source modification is required to integrate with your product, that sounds like a failing from the memcached perspective. It seems like we can reach a compromise such that your products can do all the cool stuff they do with rich support from memcached, but without memcached having to specifically support your products (unless I'm misunderstanding).
