3 ms·

> Isn't that something like SQL Server Query Notifications Yes, very similar, but there are a few major differences -- open-source product, horizontally scalab

> Isn't that something like SQL Server Query Notifications Yes, very similar, but there are a few major differences -- open-source product, horizontally scalable, json data model, packaging/api designed for web developers from the ground up. When you add all of these up, the differences are quite dramatic. > I really hope at one point you reconsider the driver model. Yes -- after 2.0 is out, we'll start bringing the community drivers under the official umbrella.

ntoshev 12y ago
I am yet to read that blog post, but it seems to me that this problem should be solved at a different level. The issue is that modern application need to work on mobiles and browsers, and be responsive. To be responsive you need to bring the part of the state that can be reached via the UI to the device. This suddenly makes your database distributed among your servers and your client devices. The device may be a mobile phone or a laptop in an airplane, and it needs to work offline and on networks with high latency. This means you need to have an eventually consistent AP database across servers, browsers and mobiles. Currently databases assume they live on servers and we hack our way with distributed state on the clients, but I hope this won't last.
- coffeemug 12y ago
  We're operating off of two hypotheses: - Eventually consistent systems are fundamentally more difficult to program for average developers than immediately consistent ones (and when a more convenient system is an option, it wins) - Connectivity is improving and will continue to improve, so immediately consistent systems will always be a strong option It remains to be seen whether these hypotheses prove to be correct in practice. We'll find out soon.
MichaelGG 12y ago
That's excellent. I was recently looking for a simple storage system and went with Elasticsearch despite it not fitting perfectly, because the interface worked well from Rust and F#. I was mainly interested in auto replication/HA. Rethink would have been a better choice, but the driver situation made me decide I didn't want to take on the risk. Looking forward to 2.0.

ntoshev 12y ago

I am yet to read that blog post, but it seems to me that this problem should be solved at a different level. The issue is that modern application need to work on mobiles and browsers, and be responsive. To be responsive you need to bring the part of the state that can be reached via the UI to the device. This suddenly makes your database distributed among your servers and your client devices. The device may be a mobile phone or a laptop in an airplane, and it needs to work offline and on networks with high latency. This means you need to have an eventually consistent AP database across servers, browsers and mobiles. Currently databases assume they live on servers and we hack our way with distributed state on the clients, but I hope this won't last.

coffeemug 12y ago
We're operating off of two hypotheses: - Eventually consistent systems are fundamentally more difficult to program for average developers than immediately consistent ones (and when a more convenient system is an option, it wins) - Connectivity is improving and will continue to improve, so immediately consistent systems will always be a strong option It remains to be seen whether these hypotheses prove to be correct in practice. We'll find out soon.

MichaelGG 12y ago

That's excellent. I was recently looking for a simple storage system and went with Elasticsearch despite it not fitting perfectly, because the interface worked well from Rust and F#. I was mainly interested in auto replication/HA. Rethink would have been a better choice, but the driver situation made me decide I didn't want to take on the risk. Looking forward to 2.0.