[Webkit-unassigned] [Bug 149850] Reinstate support for SharedWorkers

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=149850

Ian Lovejoy <ian at actualarchitecture.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ian at actualarchitecture.com

--- Comment #29 from Ian Lovejoy <ian at actualarchitecture.com> ---
I also would like this feature, with the same use cases as everyone else: a shared WebSocket connection, and single-threaded access to persistent state.

While it is true that integrity of persistent state stored in IndexedDB can be ensured by transactions (after all we all do this on the server side), this seems like more complexity than should be required for a client app running on the same machine as the data store. Also it defeats some important optimizations such as reliable maintenance of in-memory derived data calculated from the persistent state.

Actually what would be even better than SharedWorker support is simply letting multiple tabs/windows from the same origin share a UI thread and memory space (as I believe is already done when one window opens another?) This would cover all of the above use cases and also eliminate the need for a messaging layer between tabs/windows. This is of course the way all native apps work, and models the user's expectation that multiple tabs/windows reflect different views of an underlying shared model.

Example usage:

// hypothetical new sharedContext property
if (window.sharedContext.userData == null) {
    // guaranteed to only happen once due to shared UI thread
    window.sharedContext.userData = new MySharedControllerObject();
}
const myListener = new MyLocalListenerObject();
window.sharedContext.userData.addListener(myListener);

I think something like this will be required if we are ever going to bring web applications on par with native apps in terms of performance and offline use.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20210416/888c1eaa/attachment.htm>