> > 1) Sampling useful data out of a cluster. > > > > 2) Providing something useful for application developers > > > > The second case is an OS X user who fires up memcached locally, writes > > some rails code, then wonders what's going on under the hood. 1-in-1000 > > sampling there is counterproductive. Headers only is often useless. > > > > stats cachedump is most often used for the latter, and everyone needs to > > remember that users never get to 1) if they can't figure out 2). Maybe I > > should flip those priorities around? > > > > I certainly agree that you want both of these features. However they > are wildly different. (1) is for monitoring in production, and (2) is > for testing and troubleshooting. The requirements are so divergent that > there may not be any overlap at all in the implementation of each. In > fact the more separate they are the better because there is a lot of > pressure on (1) to be ultra-stable and never change, while you are > likely to think of new ideas for (2) all the time. > > So there's no need to hesitate if you can already do (1) today. Let's > face it, you have been very successful and there are rather a lot of > users who have already gotten past (2) :)
Okay, I'm kinda tired of that argument. Just beacuse you say something isn't possible, doesn't mean we can't make it work anyway. If you believe they're divergent, stop saying that they're divergent and prove it with examples. However I'd rather spend my time writing features than pretending to know if a theoretical patch will work or not. We want to work towards a system that can encompass a replacement for "stats cachedump". If we can design something which generates sflow as a subset, that'll be totally amazing! We can even use your patches as reference for creating a core shipped plugin. If people want to use sflow today, they can apply your patches and use it. As is such with open source. -Dormando
