3 ms·

Yep, I also wanted to add that if you use Mac, or Unix you most likely don't use VT-100. Yes, they all support VT-100, but that's because it became a standard,

by takeda 10y ago

Yep, I also wanted to add that if you use Mac, or Unix you most likely don't use VT-100. Yes, they all support VT-100, but that's because it became a standard, and essentially any device understands it. For example if you connect to a network switch you know that it will at least support VT-100 so you have a common protocol to communicate with it, and be able to switch to a modern protocol if the device supports it. I feel like the author is a front end developer and just hates the fact that JavaScript in the browser can't communicate with a database server directly. I don't understand though, if there is a need for something like that, and it is also possible that database could provide a generic enough interface that would work, then there must be an application that you install together with the database which would do exactly what he wants. There's no need to add this functionality to a database, because it only adds a complexity that majority of people who use a database won't need.

josephg 10y ago
> I feel like the author is a front end developer and just hates the fact that JavaScript in the browser can't communicate with a database server directly. Author here. I hate the fact that here in 2017 we still write login code, again, for every application. I hate the fact that if I want to trigger re-renders, or run workers off database changes all my options suck. > it is also possible that database could provide a generic enough interface that would work Exactly. It doesn't have to suck - our databases could provide a nice interface to do all this stuff cleanly instead. We just need a resumable event stream, with versions and some other API tweaks and we can do computed views out-of-process of the database, written in whatever language I want. I'm firmly of the opinion that all databases should provide a Samza / Storm / Kafka / etc style event log.
- takeda 10y ago
  If the problem was as simple you make it, you could write your backend code only once, then re-use it in every project. Why you are expecting a relational database which has many more use cases than the web programming (and web is not even a primary one) to solve this difficult task for small use cases? Anyway, there were attempts in solving this and those were called frameworks, which shows that hardly there's a one size fit all. If you use a framework and have complex project you reach a point where the framework will just stay in your way. > Exactly. It doesn't have to suck - our databases could provide a nice interface to do all this stuff cleanly instead. We just need a resumable event stream, with versions and some other API tweaks and we can do computed views out-of-process of the database, written in whatever language I want. Not really, a database as name suggests is meant for storing data, it's an already a difficult task by itself (if you want durability and still make it fast). What you need is a backend code that provides this functionality. > I'm firmly of the opinion that all databases should provide a Samza / Storm / Kafka / etc style event log. All the technologies you described are stream processors, while they work on data, they operate completely different than a database and they have different use cases. Postgres does have LISTEN/NOTIFY but that's meant more like a side channel for communication. Perhaps what you need is AQMP?

by takeda 10y ago

josephg 10y ago

> I feel like the author is a front end developer and just hates the fact that JavaScript in the browser can't communicate with a database server directly. Author here. I hate the fact that here in 2017 we still write login code, again, for every application. I hate the fact that if I want to trigger re-renders, or run workers off database changes all my options suck. > it is also possible that database could provide a generic enough interface that would work Exactly. It doesn't have to suck - our databases could provide a nice interface to do all this stuff cleanly instead. We just need a resumable event stream, with versions and some other API tweaks and we can do computed views out-of-process of the database, written in whatever language I want. I'm firmly of the opinion that all databases should provide a Samza / Storm / Kafka / etc style event log.

takeda 10y ago
If the problem was as simple you make it, you could write your backend code only once, then re-use it in every project. Why you are expecting a relational database which has many more use cases than the web programming (and web is not even a primary one) to solve this difficult task for small use cases? Anyway, there were attempts in solving this and those were called frameworks, which shows that hardly there's a one size fit all. If you use a framework and have complex project you reach a point where the framework will just stay in your way. > Exactly. It doesn't have to suck - our databases could provide a nice interface to do all this stuff cleanly instead. We just need a resumable event stream, with versions and some other API tweaks and we can do computed views out-of-process of the database, written in whatever language I want. Not really, a database as name suggests is meant for storing data, it's an already a difficult task by itself (if you want durability and still make it fast). What you need is a backend code that provides this functionality. > I'm firmly of the opinion that all databases should provide a Samza / Storm / Kafka / etc style event log. All the technologies you described are stream processors, while they work on data, they operate completely different than a database and they have different use cases. Postgres does have LISTEN/NOTIFY but that's meant more like a side channel for communication. Perhaps what you need is AQMP?