I'm requesting a TAG review of Bluetooth RFCOMM in Web Serial API.
The Bluetooth RFCOMM (Radio frequency communication) protocol provides emulated RS-232 serial ports. This feature would enable applications to make connections to RFCOMM services on paired Bluetooth Classic devices using the Web Serial API.
Relevant time constraints or deadlines: We expect to start an experiment with this feature in Chrome 116
The group where the work on this specification is currently being done: WICG
The group where standardization of this work is intended to be done (if current group is a community group or other incubation venue): Device & Sensors Working Group
Major unresolved issues with or opposition to this specification:
Apple and Mozilla are both opposed to Web Serial API
This work is being funded by: Google Chrome
You should also know that...
The feature can be enabled in Chrome 116 with the flag chrome://enable-bluetooth-spp-in-serial-api.
We'd prefer the TAG provide feedback as (please delete all but the desired option):
💬 leave review feedback as a comment in this issue and @-notify @nondebug
Sangwhan: unclear what hardware they want to support with this
Amy: they list negative signals from Gecko and Webkit
Sangwhan: hareware that uses is is either industrial or 20 years old
Dan: often eg. if you talk to people at Intel they're talking about industrial things like tractors. Is this an industrial use case, or a maker community use case? Would be interesting to know. They're not talking about specific platforms or devices in their motivation.
Sangwhan: I have a multimeter that uses RFCOMM. It would be cool if that worked, but seems like a lot of overhead for the web platform.
Dan: why isn't this happening in the web bluetooth cg?
[digging into history]
Sangwhan: HID makes sense because webusb can't see it unless you kick it into a special mode, disconnect and reconnect. Serial makes sense because of how OS treats it. Web bluetooth for same reasons will not really make sense, if the device is paired it's paired as a serial port. I don't know how it would work if you did the pairing from the browser. Still would be OS pairing. Ultimately I'm unconcinced about use cases
Dan: we could ask them to be concrete about devices they propose need to be connected to the web.
Amy: there are a lot of use cases in the various standards position threads from people in the community
Sangwhan: very specific use cases with a lot of baggage for the web platform
Dan: sympathetic to use cases from maker community
We discussed this during our vF2F today - we can see the appeal of WebSerial (at least the somewhat niche use cases where it could be useful), but had a hard time coming up with a compelling user story where this would get mass adoption. What would be a use case (that is appealing to a reasonably large group of users)?
We discussed this during our vF2F today - we can see the appeal of WebSerial (at least the somewhat niche use cases where it could be useful), but had a hard time coming up with a compelling user story where this would get mass adoption. What would be a use case (that is appealing to a reasonably large group of users)?
Max: if you look into the lego example - they use web bluetooth API - not serial API... so from some perspective it's not a justification for web serial for bluetooth - because that use case is not described. They use 2 APIs - one is web bluetooth API - normal bluetooth to connect the web browser to the LEGO hub - the other option is to use web serial API connection – this requires USB cable. In this use case they don't require web serial API over bluetooth. In my view if you already have bluetooth why not just use bluetooth to do the connection?
We discussed this during our vF2F today - we can see the appeal of WebSerial (at least the somewhat niche use cases where it could be useful), but had a hard time coming up with a compelling user story where this would get mass adoption. What would be a use case (that is appealing to a reasonably large group of users)?
Re cynthia, maxpassion: "compelling user story where this would get mass adoption": I've already seen this by walking into a school and seeing https://vex.com robotics being used - they're used widely. Google also showcased the similar https://spike.legoeducation.com/ this year at Google IO & Connect events.
People expect computing technology to work, even if infrequently. Serial has a variety of applications from education, home automation, enterprise/industrial, maker, and common consumer devices. These range from frequent daily use (e.g. point of sale devices, inventory tools, industrial sensors) to infrequent (e.g. configuration of consumer devices).
In the TPAC 2022 Breakout session Device APIs (Bluetooth, HID, Serial, USB) slides (PDF copy) I discuss the adoption at a larger scale. In the year since that presentation Serial usage has peaked at more than 4 times the usage we'd seen previously.
Bluetooth RFCOMM is a request the Chrome team has had from multiple partners, the top two that come to mind are in education and consumer devices, with weekly and monthly frequency use cases respectively, both from highly recognized global brands. Their devices already use Bluetooth RFCOMM protocol and they won't be changing the hardware/firmware for these. For the web to meet the need we are implementing this approach. The alternative is that developers like these meet the user's needs with e.g. windows apps or fail to meet the needs on Chromebooks. Even on Windows, partners indicate the high value of e.g. not requiring teachers/children to try to install and manage other applications vs just using the web app.
Sangwhan: the permission model - serial needs permission and bluetooth needs permission - those are separate. How does that work? Do you need both bluetooth and serial at the same time? The permission gate would be at a different API surface trigger... couldn't see how that's supposed to work. There might be cases where you want to grant browser enumeration of serial devices but not bluetooth serial?
Yves: you will enumerate on bluetooth and then it ..
Dan: feels to me this is something the browser should be doing - seems like this is a bluetooth thing but it's using the serial profile so browser exposes it using the webserial api to the application and as far as the app is concerned it's a serial device
Sangwhan: so browser does the initial... pairing process.. at the point you paired.. is that required before you can enumerate a serial port?
Dan: in that case.. most devices have a mechnism to pair a bluetooth thing that's built into the OS. Why not have the device do the pairing? Abstract away the fact that's bluetooth. Why does the web application have to know that it's bluetooth? Why doesn't it just see it as a serial device and bluetooth is hidden away
Sangwhan: that's what I think I'm reading from the explainer. There's an implication that the bluetooth connection has already been made and that i'tll be exposed a serial, but who does the bluetooth pairing? If it's the browser.. what is the lifecycle that goes from bluetooth pairing to this. I don't undderstand how that's supposed to work. If the implication is that the OS is supposed to have paired it .. if it's a serial port already at the point it reaches the browser that's fine, but what if you want to do it fully on the browser? How do permissions work in that case?
Dan: agree. It's obviously using the serial api
Sangwhan: but what happens before that
Dan: what's the full flow
Sangwhan: it's valid to answer that it's supposed to be paired at the OS level. But then I have questions about ChromeOS.. (homework for myself)
Dan: drafted my comment.. I'm personally not against this API. I'll leave it and Sangwhan you can follow up with anything additional
<blockquote>
There's no doubt that communicating with devices, particularly in an educational context as you've elaborated, is a compelling use case for computer programs. Clearly, however, there is a difference of opinion amongst implementers about whether web applications should be empowered to make such connections.
We've also reviewed the web serial API - for which we recognized the use case but also we expressed concerns about multi-stakeholder support.
Speaking personally, I'm a big supporter of these APIs. I've personally demonstrated Web Bluetooth on stage at developer events. I fully get it. However, as TAG I have to acknolwedge that the development of these capabilities has not brought other implementers along.
Putting aside the multi-stakeholder considerations, we're not clear on some aspects of the user flow and permission model. The explainer could benefit from spelling out how a device gets connected, how the permissions are requested, etc... ?
Hi @scheib thanks for that. There's no doubt that communicating with devices, particularly in an educational context as you've elaborated, is a compelling use case for computers. Clearly, however, there is a difference of opinion amongst implementers about whether web applications should be empowered to make such connections.
We've also reviewed the web serial API - for which we recognized the use case but also we expressed concerns about multi-stakeholder support.
Speaking personally, I'm a big supporter of these APIs. I've personally demonstrated Web Bluetooth on stage at developer events. I fully get it. However, as TAG I have to acknowledge that the development of these capabilities has not brought other implementers along.
Putting aside the multi-stakeholder considerations, we're not clear on some aspects of the user flow and permission model. The explainer could benefit from spelling out how a device gets connected, how the permissions are requested, etc... ?
Dan: considering this is building on top of web serial, which we did not have negative feedback on, and that they have documented use cases and user needs - specifically in the education space - it feels like this should get a "satisified with concerns" from us - the concerns being the multi-stakeholder support which is really the underlying web serial and web bluetooth.
Sangwhan: OK with that. No concerns with the design.
Dan: will set to proposed closing and we can close at the plenary.
As reflected in our minutes from 09-25 week we are closing this as "satisfied with concerns." We're happy with the design and we understand the user need. We remain concerned about the lack of overall support for the underlying web serial and web bluetooth specs themselves. We'd like to encourage you to do more to builld consensus around these specs with other browsers / browser engine makers.
OpenedJun 7, 2023
こんにちは TAG-さん!
I'm requesting a TAG review of Bluetooth RFCOMM in Web Serial API.
The Bluetooth RFCOMM (Radio frequency communication) protocol provides emulated RS-232 serial ports. This feature would enable applications to make connections to RFCOMM services on paired Bluetooth Classic devices using the Web Serial API.
Further details:
You should also know that...
The feature can be enabled in Chrome 116 with the flag chrome://enable-bluetooth-spp-in-serial-api.
We'd prefer the TAG provide feedback as (please delete all but the desired option):
💬 leave review feedback as a comment in this issue and @-notify @nondebug