35:T4c4,Yes, it is a key/value store as base technology. The important thing is that you can build anything you want on top, which includes for example indexes and such. The idea is that this can/will be implemented on top of a simple base protocol, which is easy to implement, and to use data modules (and shared utility modules) to add more complex functionality.

However, having used RS apps for years now, I think it's worth mentioning that most people considerably over-estimate the amount and size of the personal data they use daily, and in the case of notes, I never had performance issues with Litewrite pulling all my notes whenever/wherever I connect my storage: https://litewrite.net/

That's not just because this is actually pretty fast with multiplexing on HTTP/2, but also because you usually don't connect and disconnect all the time on all your devices. So you will usually have your existing data cached and available on app startup (including when you're offline), and only sync remote changes when you get online. This is also what similar proprietary apps like e.g. Google Keep do.36:T45f,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.37:T43c,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...38:T422,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