5 ms·

I get the need to standarize properly WebSQL, but the two different implementations "rule" is often ignored in the implementation of crypto, compression, image

I get the need to standarize properly WebSQL, but the two different implementations "rule" is often ignored in the implementation of crypto, compression, image decoding, etc. where different browsers often share code with a common ancestor (or just identical). If SQLite gets new features you do the same thing you do with other specs. If it makes sense to expose them, you update the spec.

aseipp 10y ago
But there are multiple competing implementations of GIF, JPEG, and thousands of other image file formats, and the browsers vary in exactly what code they use. Browsers actually DO use multiple TLS/SSL stacks (NSS, BoringSSL, OpenSSL at least), and multiple implementations of tons of protocol components (like compression) are around as they need to test things like performance. Multiple implementations of e.g. WebRTC exist. You could replace any of these components with a completely different implementation with relative ease, because other implementations do, in fact, exist. Furthermore, outside of the TLS case, most of those are still within the ballpark of reason -- feasible to reimplement even in a small group. That's definitely something to be considered -- it's not just a case of if it's possible, but whether at all it's even realistically feasible for most people to reimplement. Replacing WebSQL is on a completely different level of difficulty compared to these. Not only is it massively more complex to implement, there really is only one implementation, so it's pretty much impossible to reimplement exactly to spec, with the same kind of performance/usability characteristics -- without just doing a clean-room analysis of SQLite. > If SQLite gets new features you do the same thing you do with other specs. If it makes sense to expose them, you update the spec. It's never that easy. What happens if SQLite changes the way a feature behaves, even for good reason? The developers aren't beholden to browser devs, so this is within their right. What happens if they don't change something and a bug is then "enshrined" as part of the implementation -- or what if someone wants to make a change like, I dunno, actually checking the types of values you insert into the DB? I do think WebSQL was promising and it does suck it was axed. But I think it was axed for a fairly sound reason, even if humans aren't always perfect robots who make exactly perfect decisions in similar instances (e.g. a similar difficulty argument could be made against TLS, although we're already waaay past that point).
- SQLite 10y ago
  > What happens if SQLite changes the way a feature behaves, even for good reason? The developers aren't beholden to browser devs, so this is within their right. Actually, we are beholden to application developers of all types. It's part of the SQLite social contract. SQLite does not change in incompatible ways. New features are added, performance is enhanced, but we work hard to not break any of the millions and millions of diverse applications that use SQLite.

aseipp 10y ago

But there are multiple competing implementations of GIF, JPEG, and thousands of other image file formats, and the browsers vary in exactly what code they use. Browsers actually DO use multiple TLS/SSL stacks (NSS, BoringSSL, OpenSSL at least), and multiple implementations of tons of protocol components (like compression) are around as they need to test things like performance. Multiple implementations of e.g. WebRTC exist. You could replace any of these components with a completely different implementation with relative ease, because other implementations do, in fact, exist. Furthermore, outside of the TLS case, most of those are still within the ballpark of reason -- feasible to reimplement even in a small group. That's definitely something to be considered -- it's not just a case of if it's possible, but whether at all it's even realistically feasible for most people to reimplement. Replacing WebSQL is on a completely different level of difficulty compared to these. Not only is it massively more complex to implement, there really is only one implementation, so it's pretty much impossible to reimplement exactly to spec, with the same kind of performance/usability characteristics -- without just doing a clean-room analysis of SQLite. > If SQLite gets new features you do the same thing you do with other specs. If it makes sense to expose them, you update the spec. It's never that easy. What happens if SQLite changes the way a feature behaves, even for good reason? The developers aren't beholden to browser devs, so this is within their right. What happens if they don't change something and a bug is then "enshrined" as part of the implementation -- or what if someone wants to make a change like, I dunno, actually checking the types of values you insert into the DB? I do think WebSQL was promising and it does suck it was axed. But I think it was axed for a fairly sound reason, even if humans aren't always perfect robots who make exactly perfect decisions in similar instances (e.g. a similar difficulty argument could be made against TLS, although we're already waaay past that point).

SQLite 10y ago
> What happens if SQLite changes the way a feature behaves, even for good reason? The developers aren't beholden to browser devs, so this is within their right. Actually, we are beholden to application developers of all types. It's part of the SQLite social contract. SQLite does not change in incompatible ways. New features are added, performance is enhanced, but we work hard to not break any of the millions and millions of diverse applications that use SQLite.