Re: [w3ctag/design-reviews] Review Request: WebUSB on Dedicated and Shared Workers (#277)

I assume there is interest in doing something similar for Web Bluetooth, and we have also thought about doing something like that for Generic Sensor API.

In Chrome at least, these implementations already run in a separate thread as the main browser UI, and communicate via IPC / shared memory, so whether something is being accessed from the main browser thread or a worker shouldn't matter that much. With the Generic Sensors, each physical sensor can be accessed from multiple sensor objects, sharing the data. I think that makes sense when using from the same context, and in the case of sensors, but both Web Bluetooth and Web USB create single connections, so they should only be accessed from one place.

In this case (looking at the explainer) there is a transfer involved. Ie. you request the device on the main browser / UI thread, and then transfer the connection to the worker. So I would say that is solved here, and I think the solution is quite fine.

I am more interested in what happens when the browser tab (or site on mobile) gets backgrounded - I assume that it will share the same behavior as when running in the main browser thread as today, and thus loose connection? Do you intent on looking at making changes around this in the future?

Also I don't get why you have to request a device on the browser main thread and then still list all devices on the worker and find the one that matched and then open() it. Can't we not just transfer over the object instead, somehow? Like can't it be a Transferable object like ArrayBuffer, MessagePort and ImageBitmap? 

-- 
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/277#issuecomment-385354579