6 ms·

WebSQL when? @Firefox devs: please add WebSQL support. Now that you lost the IndexedDB devs who voted against WebSQL, it's rather time. Mind you, NoSQL and New

by frik 9y ago

WebSQL when? @Firefox devs: please add WebSQL support. Now that you lost the IndexedDB devs who voted against WebSQL, it's rather time. Mind you, NoSQL and NewSQL nowadays coexist next to each other. Safari and Chrome based browsers (90% global market share) support WebSQL, except Firefox.

nextInt 9y ago
No this is not websql. This allows remote hosting so data across multiple devices can be in sync
- aeorgnoieang 9y ago
  One of the four 'features' mentioned on the home page is "Offline" so presumably some kind of browser local storage is supported.
Klathmon 9y ago
Until WebSQL gets a full spec, I personally am completely against it. Right now it's defined as "What SQLite does", which is not a way to implement a standard. Not to mention that even if they did create a full "specification" for the SQL that it uses, it seems like way too much to force onto a browser to develop for not all that much benefit. Safari and Chrome both support it, but it's not going to get any major updates and only exists in the browser today because it was added at one point.
- aeorgnoieang 9y ago
  But isn't "What SQLite does" effectively a standard? It's got a spec AFAIK.
  - Klathmon 9y ago
    A core part of web technologies is the fact that they have multiple competing implementations. For example, javascript changes can't be put into a standard until they have (IIRC) 3 major browsers which implement them. Pinning a standard to a specific implementation (and a specific version) is the opposite of every other web standard. Plus it means that any alternate implementations must reimplement SQLite themselves if they don't want to or can't use SQLite themselves.
    - aeorgnoieang 9y ago
      I'm confused about what would be implemented. Is it a database engine that supports the SQL dialect that SQLite uses. In which case, (at least) two browsers have already implemented it, right? If you're referring to SQLite itself being implemented multiple times, I don't understand why that's relevant to Web SQL. You wrote that Web SQL shouldn't be supported, i.e. implemented, until there's a spec. It seems like there's a 'spec' now, if not an official formal spec. But now you're claiming that Web SQL can't be a standard because there aren't multiple implementations. But it certainly seems like there are already multiple implementations: - [Can I use... Support tables for HTML5, CSS3, etc](https://caniuse.com/#feat=sql-storage https://caniuse.com/#feat=sql-storage) But still, your logic seems circular: Web SQL shouldn't be implemented for all the browsers because there's no spec and there's no spec because there aren't multiple implementations. I imagine there's a distinction you're trying to convey that I'm missing. What is it?
      - Klathmon 9y ago
        The implementations currently are just SQLite hooked into the browser, they aren't different in any real way. It is a bit circular, but generally something gets proposed as a standard, multiple browsers will implement it, then it becomes a finalized standard. In this case it was proposed, the standard says "your implementation needs to do what this other implementation does" (and no other information is given about the SQL system), 2 browsers (really 1 engine at the time, webkit) used SQLite directly, and it never went anywhere else. I guess my point isn't that there's not a "spec", but that the spec that there is doesn't say anything about the SQL part of WebSQL, it just says what the interface to the SQL engine looks like, and then mandates that the SQL engine act, look, and work like the one in a specific version of SQLite.
- dude01 9y ago
  Rules are great, and you're right that there's a rule that something cannot be a browser-standard unless it's a real standard, with real generic specs. BUT... what about making an exception to the rule? SQLite is sort of a unique beast -- public domain license, used almost everywhere (most smart phones have it embedded, Chrome and Safari have it), and rock solid? Also, it's not like it's a 100 million LOC app.
  - Klathmon 9y ago
    Because despite how great SQLite is (I use and love it myself), removing the "competition" between multiple implementations is removing one of the main cornerstones of the web platform. A real spec is "loose", it allows wiggle room in many areas, it allows for multiple ways to implement things, it allows implementations to act differently, and in most cases that comes out as a win for the user. Saying the spec should do what a single implementation does is about as close to saying "you aren't allowed to improve this" as you can get. I really believe that a monoculture is a bad thing. Luckily on most platforms SQLite (while the best in most cases) doesn't have a monopoly on what it does, and while it's a "defacto" standard in many cases, there are alternatives at every step of the way. Saying that a platform must implement SQLite takes that defacto standard and codifies it. It's forcing a monoculture. It doesn't just deincentivise improvement, it almost explicitly forbids it.
    - dude01 9y ago
      I see you got a response from "SQLite" elsewhere in this thread, with same thought I had -- just document the subset of SQL to be supported. I would say it's too late, but... SQL has been around for decades, and I think it will be around for decades more, so it probably deserves to be baked into the browser.
- SQLite 9y ago
  I will be happy to write a spec for a cut-down SQL language (a subset of the language understood by SQLite) for WebSQL, and provide a "strict" flag for SQLite to force it to understand all and only the spec language. The prerequisite for doing this is that you (or anybody else, as long as it isn't me) need to get all the browser vendors on-board and promising to implement WebSQL if I write the spec. The cut-down SQL would include just the basics: CREATE TABLE, CREATE INDEX, INSERT, UPDATE, DELETE, SELECT. No triggers or views. No support for partial indexes or indexes on expressions, common table expressions, or other such features. There would be a minimal set of built-in SQL functions, but with support for application-defined SQL functions written in javascript. A competing implementation would not need to understand the SQLite file format nor the complete SQLite language nor would it need to implement the SQLite API. All it would need to do is support the basic SQL subset defined by the spec. If you get the browser vendors on-board with this idea, and I'll write the spec.
  - Klathmon 9y ago
    While I'd love to see this happen, I'm not even sure where I would begin. But if someone out there has experience working with whatwg or W3C on these kinds of things and wants someone to help out, I'd love to be a part of it. But like you said, the hardest part is getting the different browser engines to promise support (or even take it seriously). I remember reading on HN a post from a woman who was involved in trying to get SVG in the browser standardized (sadly I can't seem to find it any more!), and just reading about the struggles she went through to even talk to someone involved who, while receptive, basically told her that it wasn't going to get done. It seems like there would need to be an "advocate" who is part of the teams on EdgeHTML and Gecko that would be willing to fight for it before it would even begin, otherwise, like you said, it would all basically be wasted effort. The JavaScript standardization system is quite nice, I wish that browsers could get together and come up with something similar for Web APIs...

by frik 9y ago

nextInt 9y ago

No this is not websql. This allows remote hosting so data across multiple devices can be in sync

aeorgnoieang 9y ago
One of the four 'features' mentioned on the home page is "Offline" so presumably some kind of browser local storage is supported.

Klathmon 9y ago

Until WebSQL gets a full spec, I personally am completely against it. Right now it's defined as "What SQLite does", which is not a way to implement a standard. Not to mention that even if they did create a full "specification" for the SQL that it uses, it seems like way too much to force onto a browser to develop for not all that much benefit. Safari and Chrome both support it, but it's not going to get any major updates and only exists in the browser today because it was added at one point.

aeorgnoieang 9y ago
But isn't "What SQLite does" effectively a standard? It's got a spec AFAIK.
- Klathmon 9y ago
  A core part of web technologies is the fact that they have multiple competing implementations. For example, javascript changes can't be put into a standard until they have (IIRC) 3 major browsers which implement them. Pinning a standard to a specific implementation (and a specific version) is the opposite of every other web standard. Plus it means that any alternate implementations must reimplement SQLite themselves if they don't want to or can't use SQLite themselves.
  - aeorgnoieang 9y ago
    I'm confused about what would be implemented. Is it a database engine that supports the SQL dialect that SQLite uses. In which case, (at least) two browsers have already implemented it, right? If you're referring to SQLite itself being implemented multiple times, I don't understand why that's relevant to Web SQL. You wrote that Web SQL shouldn't be supported, i.e. implemented, until there's a spec. It seems like there's a 'spec' now, if not an official formal spec. But now you're claiming that Web SQL can't be a standard because there aren't multiple implementations. But it certainly seems like there are already multiple implementations: - [Can I use... Support tables for HTML5, CSS3, etc](https://caniuse.com/#feat=sql-storage https://caniuse.com/#feat=sql-storage) But still, your logic seems circular: Web SQL shouldn't be implemented for all the browsers because there's no spec and there's no spec because there aren't multiple implementations. I imagine there's a distinction you're trying to convey that I'm missing. What is it?
    - Klathmon 9y ago
      The implementations currently are just SQLite hooked into the browser, they aren't different in any real way. It is a bit circular, but generally something gets proposed as a standard, multiple browsers will implement it, then it becomes a finalized standard. In this case it was proposed, the standard says "your implementation needs to do what this other implementation does" (and no other information is given about the SQL system), 2 browsers (really 1 engine at the time, webkit) used SQLite directly, and it never went anywhere else. I guess my point isn't that there's not a "spec", but that the spec that there is doesn't say anything about the SQL part of WebSQL, it just says what the interface to the SQL engine looks like, and then mandates that the SQL engine act, look, and work like the one in a specific version of SQLite.
dude01 9y ago
Rules are great, and you're right that there's a rule that something cannot be a browser-standard unless it's a real standard, with real generic specs. BUT... what about making an exception to the rule? SQLite is sort of a unique beast -- public domain license, used almost everywhere (most smart phones have it embedded, Chrome and Safari have it), and rock solid? Also, it's not like it's a 100 million LOC app.
- Klathmon 9y ago
  Because despite how great SQLite is (I use and love it myself), removing the "competition" between multiple implementations is removing one of the main cornerstones of the web platform. A real spec is "loose", it allows wiggle room in many areas, it allows for multiple ways to implement things, it allows implementations to act differently, and in most cases that comes out as a win for the user. Saying the spec should do what a single implementation does is about as close to saying "you aren't allowed to improve this" as you can get. I really believe that a monoculture is a bad thing. Luckily on most platforms SQLite (while the best in most cases) doesn't have a monopoly on what it does, and while it's a "defacto" standard in many cases, there are alternatives at every step of the way. Saying that a platform must implement SQLite takes that defacto standard and codifies it. It's forcing a monoculture. It doesn't just deincentivise improvement, it almost explicitly forbids it.
  - dude01 9y ago
    I see you got a response from "SQLite" elsewhere in this thread, with same thought I had -- just document the subset of SQL to be supported. I would say it's too late, but... SQL has been around for decades, and I think it will be around for decades more, so it probably deserves to be baked into the browser.
SQLite 9y ago
I will be happy to write a spec for a cut-down SQL language (a subset of the language understood by SQLite) for WebSQL, and provide a "strict" flag for SQLite to force it to understand all and only the spec language. The prerequisite for doing this is that you (or anybody else, as long as it isn't me) need to get all the browser vendors on-board and promising to implement WebSQL if I write the spec. The cut-down SQL would include just the basics: CREATE TABLE, CREATE INDEX, INSERT, UPDATE, DELETE, SELECT. No triggers or views. No support for partial indexes or indexes on expressions, common table expressions, or other such features. There would be a minimal set of built-in SQL functions, but with support for application-defined SQL functions written in javascript. A competing implementation would not need to understand the SQLite file format nor the complete SQLite language nor would it need to implement the SQLite API. All it would need to do is support the basic SQL subset defined by the spec. If you get the browser vendors on-board with this idea, and I'll write the spec.
- Klathmon 9y ago
  While I'd love to see this happen, I'm not even sure where I would begin. But if someone out there has experience working with whatwg or W3C on these kinds of things and wants someone to help out, I'd love to be a part of it. But like you said, the hardest part is getting the different browser engines to promise support (or even take it seriously). I remember reading on HN a post from a woman who was involved in trying to get SVG in the browser standardized (sadly I can't seem to find it any more!), and just reading about the struggles she went through to even talk to someone involved who, while receptive, basically told her that it wasn't going to get done. It seems like there would need to be an "advocate" who is part of the teams on EdgeHTML and Gecko that would be willing to fight for it before it would even begin, otherwise, like you said, it would all basically be wasted effort. The JavaScript standardization system is quite nice, I wish that browsers could get together and come up with something similar for Web APIs...