Intent To Implement: IndexedDB Observers

[Daniel Murphy]

Contact emails

dmu...@chromium.org, pal...@chromium.org

Spec

https://github.com/dmurph/indexed-db-observers/blob/gh-pages/EXPLAINER.md

Summary

IndexedDB observers allow a developer to listen to changes to their database, including changes from other browsing contexts.

Motivation

IndexedDB spans multiple browsing contexts (tabs, workers, etc) and there is no way to observe changes across all of these contexts. Trying to use a javascript wrapper involves a lot of piping and complex ack-ing (basically rolling your own transaction locking model) if there needs to be data consistency during change event. Thus we want to add IDB Observers to the existing specification, which allows us to implement this in a safe and efficient manner. Use cases for observers include:

• Simplified application logic.
  
• Updating the UI from database changes (data binding).
  
• Syncing local state from background worker (like a ServiceWorker) or another tab making changes.
  
• Syncing a local database with a network database.

Interoperability and Compatibility Risk

This is additive to the current specification for IndexedDB.

Mozilla has expressed interest in this bug.

Ongoing technical constraints

None.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes.

OWP launch tracking bug

Launch bug: crbug.com/609934

Dev bug: crbug.com/457449

Link to entry on the feature dashboard

https://www.chromestatus.com/features/5669292892749824

Requesting approval to ship?

No

[Rick Byers]

Sounds exciting!

I didn't see anything in the explainer about the thread performance implications.  A critical property of workers IMHO is that they allow developers to reason about thread performance locally, (mostly) independently from that of other threads.  To what extent is that true today with IndexDB in workers?  I.e. can expensive DB transactions on a worker block the main UI thread if it calls into the same database?  Do the consistency guarantees required by observers make this any worse?

[Elliott Sprehn]

I have a couple comments on this proposal:

- This doesn't follow the observer pattern of MutationObserver, IntersectionObserver, PerformanceObserver or the upcoming ResizeObserver.

- I don't see a way to disconnect an observation, all the other ones support that.

- The filter argument is optional, we've made this mistake a couple times and I really want us to start making authors be explicit. Ex. PerormanceObserver requires you to list the record types you care about.

[Daniel Murphy]

Rick:

IndexedDB is asynchronous, so there is never any blocking of the UI thread. Observers don't introduce anything that would block a thread. The only extra 'block', per say, is the possible delay in commiting write transactions if an observer is using their optional readonly transaction to read the state of the world. But this is delaying an asynchronous callback, not any thread.

On Mon, May 9, 2016 at 9:51 PM Elliott Sprehn <esp...@chromium.org> wrote:

I have a couple comments on this proposal:

- This doesn't follow the observer pattern of MutationObserver, IntersectionObserver, PerformanceObserver or the upcoming ResizeObserver.

Nope. I'm fine with any observer pattern, as long as:

1. I can tie the lifetime of the observer to the database connection object still,
2. I can stop the observer manually, and
   
3. I can provide options for observing.

- I don't see a way to disconnect an observation, all the other ones support that.

The control that is returned from the `observe` method can be used to stop the observer (as well as check if it's running, as observers can also be stopped when the database connection is closed).

- The filter argument is optional, we've made this mistake a couple times and I really want us to start making authors be explicit. Ex. PerormanceObserver requires you to list the record types you care about.

Technically there is an inherit filter of object stores imposed by the transaction we create the observer with. So the developer is already specifically choosing the tables they want to observe. I think this is enough, and further range specification should be optional. Does that sound good? I think otherwise it would create a lot of copypasta of IDBKeyRange.lowerBound(0).

[Daniel Murphy]

Based on feedback about the observer creation, I created the following proposal:

https://github.com/dmurph/indexed-db-observers/issues/24

It makes creation similar to IntersectionObserver. Let me know what you think!

[Daniel Murphy]

Hello!

I've updated the IDB Observers Explainer. Major changes:

• It now lives in the WICG, as we've gotten public interest from Firefox.
• Construction now follows the same pattern other observers, like MutationObserver and IntersectionObserver.
• The user must now always specify the operations they care about (they cannot default to all operations).
• I elaborated on the code for various examples.

Thanks for the feedback! Let me know if you have any other ideas/concerns.

[Daniel Murphy]

Hello!

I've updated the IDB Observers Explainer. Major changes:

• It now lives in the WICG, as we've gotten public interest from Firefox.
• Construction now follows the same pattern other observers, like MutationObserver and IntersectionObserver.
• The user must now always specify the operations they care about (they cannot default to all operations).
• I elaborated on the code for various examples.

Thanks for the feedback! Let me know if you have any other ideas/concerns.

Daniel

On Mon, May 16, 2016 at 12:13 PM Daniel Murphy <dmu...@chromium.org> wrote:

[Elliott Sprehn]

Amazing!

[Daniel Murphy]

Update!

The feature is now working behind the experimental-web-platform-features flag in canary, and I think we're ready to do origin trials. The only un-implemented feature is filtering by key.

See the demo here:

https://dmurph.github.io/samples/indexed_db_observers/index.html

(working on Canary).

Thanks!

Daniel

[François Beaufort 🇫🇷]

For info, demo is also now available at https://googlechrome.github.io/samples/indexeddb-observers/ 

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.