Re: [w3ctag/design-reviews] Review request for IndexedDB Observers (#189)

I think the semantics and use cases are different enough that sharing a single event type for cookies and IDB would introduce a lot of complexity for relatively little gain; however, following a similar pattern to the proposed InstallEvent .registerCookieChangeInterest + cookiechangeevent might make sense for IDB, e.g. InstallEvent .registerIndexedDBChangeInterest + indexeddbchangeevent with registration-time interest expression analogous to those used during observer registration (though perhaps only a subset, since unlike cookies there is not a conveniently small maximum size for the reported changes and having to keep a very large buffer of operations/transactions in memory until the worker is ready to handle the event could be very bad for performance) and reported changes in the handler analogous to those reported to an IndexedDB observer.

I also think the IndexedDB and cookie uses and storage models are fairly different, including for example:

- transactional vs. non-transactional,
- explicit-key vs. tripartite partially-hidden key,
- origin-scoped and always visible vs. domain-scoped+path-scoped+name w/conditional visibility based on "secure" flag + some always-invisible-to-script "httponly" entries that nevertheless have script-observable side effects,
- persistent-until-deleted vs. persistent-until-expired-or-end-of-session,
- script-only storage vs. client ⇆ server shared storage/messaging/authentication with only a subset useful to script,
- same-origin vs. used in cross-origin federation,
- very small maximum size vs. potentially very large values, and
- cookie partial eviction model vs. IndexedDB storage full model


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/189#issuecomment-332626895