search

WICG / webusb

Connecting hardware to the web.
https://wicg.github.io/webusb/
Other
1.31k stars 131 forks source link

Define WebUSB from Service Workers #22

Closed reillyeon closed 2 years ago

reillyeon commented 9 years ago

It makes sense for a service worker to be able to react to a device being plugged in. It also makes sense for a service worker to be able to provide driver-like functionality for a device to other origins through navigator.connect. This issue is a reminder to figure out how this should work.

kenchris commented 8 years ago

Note that navigator.connect has been replaced by foreign fetch.

As Service Workers are short lived (can be killed at any time and woken up quickly again) everything will have to be stateless

joth76 commented 8 years ago

We have a Chrome App that uses the chrome.usb to synchronize data from wearable devices (like a fitness tracker) to the cloud. We'd be very keen to move this over to WebUSB, when Service Workers are available. In trials we have found that data upload in the background (i.e. without the user opening a webpage) is very important for user compliance: they want to just plug the device into their laptop and have the sync start without taking any action on the computer, as this maybe a daily activity we need it to be as low-friction as possible.

A very similar use-case (speaking as a user rather than app developer) would be for uploading my Garmin GPS data to the cloud: the current Garmin Express native app automatically syncs tracks whenever a garmin device is plugged in. It would be great for the WebUSB API to be able to provide the same level of UX.

beaufortfrancois commented 8 years ago

Glad to see you're interested in the WebUSB API.

As stated in https://www.chromestatus.com/features/5651917954875392,

The current plan is to get the main navigator.usb API surface fleshed out and working from within web frames. A second iteration on the API will look at shared worker and service worker support.

owencm commented 8 years ago

@joth76 I think the existing flow may actually work quite well in this case. Today with WebUSB a notification is popped up every time the user plugs in a WebUSB device, that provides a link to open the site associated with the device.

That means that when a user plugs in one of your devices the flow would be:

  1. User gets a notification that 'Wearable XYZ has been plugged in'
  2. User clicks notification
  3. Sync starts

There would be no step for them to remember to go somewhere or actively launch anything, it would all happen in response to the notification.

It is worth noting with WebUSB that the device itself has to specify which websites are able to access it, for security reasons. The origin provided by the device will be the one the user is prompted to open via the notification when they plug in the device.

reillyeon commented 8 years ago

My initial thoughts on this would be something like the proposed periodic sync API, replacing hints such as "when charging" or "avoid cellular" with "when $device is connected". If the page is required to specify exactly what device it will connect to when the sync request is registered the browser has the option to present the user with an option such as "This site would like to synchronize data with your ACME Fitness Band in the background whenever it is connected."

joth76 commented 8 years ago

@owencm The flow you suggest could work, although it is definitely a UX regression compared to what we currently achieve with chrome.usb due to step 2 "User clicks notification". Significantly, this also means the users must unlock their computer, turning a 2 second passive task (drop wearable into charging cradle) into a longer interactive task (wake up screen saver, enter password, wait for or seek out the popup, click it) @reillyeon Yes that sounds like a workable permission model to achieve UX parity. Presumably this would be added to "Content Settings > USB Device" to allow the user to revoke the permission if needed.

bvwj commented 7 years ago

Will Service Worker additions support Shared Workers? I would like to implement a Shared Worker to manage a stream of data from my USB device.

Is there a schedule for releasing / testing Worker functionality?

reillyeon commented 7 years ago

I will open a separate issue for specing support for Shared Workers as it should not be blocked on the permission questions raised by support for Service Workers.