Re: IndexedDB, what were the issues? Non-reactable.

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

Received on Friday, 8 March 2013 19:18:01 UTC