We need this!

[johncrim]

I really like this proposal - as an architect, it would be super-useful for our products. More generally, any time a webapp wants to support changing data in the UI ala rx.js, and that data is stored in indexeddb, this seems like the way to go. (I'm also assuming all web apps using indexeddb need to support multiple tabs, and updates can be made remotely or from other tabs). There needs to be a mechanism for update notification without polling.

However, given the lack of movement here, and lack of movement in other browsers, and the fact that the feature requires enabling an experimental flag, this doesn't seem like it's worth adopting. I'm just chiming in here as a lone voice in favor of the feature (and I don't know where else to leave this note). I appreciate the contributors work on this - frankly I'm puzzled at the apparent lack of enthusiasm from the community.

I suppose the alternative for update notification is a service worker notification relay, where all updates notify the service worker, and the service worker notifies all subscribers.

[dmurph]

To get this prioritized we need partners who are willing to participate in an origin trial:
https://github.com/GoogleChrome/OriginTrials

[0xcaff]

Is implementation of this not completely possible in the application layer? Yes, it is hard, but I think with a BroadcastChannel for communication and some code intercepting mutations there's nothing fundamentally stopping anyone from building this in userland. The versioning might get a bit tricky but it seems possible.

I'm ask because I'm attempting to build this in user land. I don't need to worry about multiple versions in my case because I'm in a WebExtension world where all the code is always a single version. Maybe a better way to get this prioritized is to build a library and get traction to show there's demand for a feature like this.

Would love if @dmurph chimes in. I have no idea how these things get prioritized (and am very curious) and also wonder if building this in userland is a fools errand.

[dmurph]

In the old plan, having the 'transaction' to read post-changes would be impossible to do in user-land. However, the new version of the explainer (not sure if I made it yet) would remove transaction, and basically just have it be key + value.

I believe this could be implemented in user-land - however I think it might be impossible to have the correct ordering... I don't think you would have a guarantee that changes would be received in the order in which they were completed.

The only absolutely-possible way to do this would be to just send the 'changed' signal with no other data, and have the listener reload the data they cared about. You could also include the keys changed, but there could be ordering issues.. I would probably want to rate-limit that signal too, as there is a tragedy-of-commons situation here.

A reasonable user-land implementation then, IMO, would send 'change' callbacks & have the keys changed, and the user code would have to be OK with possible out-of-order messages if they were looking at the keys.

[0xcaff]

I just realized the complexity around transaction snapshots while trying to implement it. 🤦 I guess transactions aren't structured cloned and even if they could, they'd probably be closed as soon as the event loop finished executing micro-tasks.

Why the change removing transaction snapshots? Seems like a useful feature. Is there complexity with implementing it?

I can probably get away with not needing transaction snapshots in my application.

Regarding ordering, good point. I've been emitting events to a BroadcastChannel on transaction complete. I guess the transaction completion event is delivered asynchronously and scheduled at the whim of any other work an event loop is doing (during which time other contexts with less congest event loops can complete transactions and post updates causing out of order messages).

And is rate limiting for performance? I guess in this spec, each observer only needs to handle messages for object stores it is subscribed to and filtering is done outside the event loop. While here it is done in the event loop for every listener of the shared channel.

Thanks for explaining. I will build my thing, if I start running into these problems I'll take a stab (time permitting) at implementing this spec in firefox (app is dependent on some webextension apis only in firefox today).