Nathan's post is very interesting - thanks for posting that. He has taken on board the implications of CAP, and built a system (Storm) that is genuinely different.
I wish more people did that. If you're going to use CAP to justify building a database but having it be less capable, that's just marketing. If you're going to look at CAP and think "OK, we can't get to 100%, but how can we get closer", then that's great. For blog marketing reasons, you might describe that as "beating the CAP theorem"; but it's actually finding new solutions within the constraints.
Good catch for April fools! I shouldn't have included that one, obviously.
For the nathan post, reading the comments reveal that he ends up acknowledging CAP is true, which would make him fall into the "( ) nice try, but blatantly false advertising" box of the list.
CAP theorem can be used as an excuse to provide weak systems that don't do much (unfortunately), but it doesn't mean it's what it is meant to validate as an idea, fortunately. As I mentioned in another comment, it's more or less a very basic set of rules (axioms?) to consider when building distributed systems.
Nathan's post is very interesting - thanks for posting that. He has taken on board the implications of CAP, and built a system (Storm) that is genuinely different.
I wish more people did that. If you're going to use CAP to justify building a database but having it be less capable, that's just marketing. If you're going to look at CAP and think "OK, we can't get to 100%, but how can we get closer", then that's great. For blog marketing reasons, you might describe that as "beating the CAP theorem"; but it's actually finding new solutions within the constraints.