Part 1 - Finding issues, preventing recurence This thread started as counter-rabble rousing. This search for problems, wanting desperately to find some, to hunt for paths for avoiding a recurence- has yielded IMO triflingly small big results.
Alex's discussion about understanding the state machine, about it not being exposed yet having rules it expects, rings true with my own small experience with IndexedDB spec reading I've done. In contrast my experience engineering IndexedDB powered play-toys constrasts strongly: the spec just works without complication for my kind of very basic use cases. And I don't see a whole lot having reviewed the core point, which wasn't this spec, but how we avoid repeating the "mistakes." Having not found much consititueable as a mistakes this is IMO a hard case to learn from- but I think that original question was a cultural one, and I'd call out that question as having gotten burried, which is natural along-side my claim that there ain't much in the way of real actual problems around here. Part 2 - An issue I do have one issue I'd raise- I'd love a more reactive data-store. When something changes it's more often the edge- the change- that is interesting than the state or the value. We've recently added what IMO is the most important advancement in the web, Observers, and damnit I demand my data-store be observable too: places to dump bits ought be on the line to report what bits are being dumped into them. Developers require all systems be able to report what's happening, without requirying the entire data set comparing versus some separate cache. This is, imo, the capital lacking area IndexedDB has failed to touch upon. I'd prefer an IndexedDB that at a minimum allows multiple active pariticpants (those holding the data-store open at the time) to see what changes are being made to the store. I'd further enjoy & relish in an IndexedDB that allowed me to setup persistent event sources that when reconnected to would report on the changes they had been set up to monitor and log. This is indeed implementable with a wrapper on top (& so was scanning the DOM for changes, but many reactive systems resorted to .get/.set wrappers alike this wrapper). I'd like to see some natural reactivity in the spec, some way for the IndexedDB to itself report what is going on inside the store beyond the scope of schema changes, rather than this being a supplemental grafted on system to the data-store. In Cassandra world, to pick one random data-store example also discussing this broad topic there's CASSANDRA-1311 - Triggers, to allow the Cassandra database to signal changes to the store and perhaps perform actions in response. I think this is an important topic that IMO has been largely overlooked, and I'd love to see a reactive data store that could be more readily used in MVC use cases to act as a system of record to populate and keep in sync dependent systems. https://issues.apache.org/jira/browse/CASSANDRA-1311 Part 3 - Thanks Thanks for reading. I'm so happy to have a data-store in the browser, and I think the spec as it stands does well what it set out to do, and I look forwards to second passes to make it look aesthetically kinder. Godspeed all. Fair regards, m rektide de la faye fowle
