I've been playing around with the new QueueReader stuff and I'm starting to believe it's at the wrong level of abstraction - in the shard context - for a user.
Between having to know about the BlurPartioner and handling all the failure nuances, I'm thinking a much friendlier approach would be to have the client implement a single message pump that Blur take's from and handles. Maybe on startup the Controllers compete for the lead QueueReader position, create it from the TableContext and run with it? The user would still need to deal with Controller failures but that seems easier to reason about then shard failures. The way it's crafted right now, the user seems burdened with a lot of the hard problems that Blur otherwise solves. Obviously, it trades off a high burden for one of the controllers. Thoughts? --tim
