Re: Scope of requestDevice(), Re: Notes from meeting between Chrome and Mozilla folks

On Mon, Aug 11, 2014 at 7:37 AM, Marcos Caceres <marcos@marcosc.com> wrote:
>
>
> On August 11, 2014 at 9:24:54 AM, Jeffrey Yasskin (jyasskin@google.com) wrote:
>> > If a website doesn't speak the same language as the device, it
>> doesn't seem like it matters what capabilities the device has; the website
>> won't be able to talk to it to take advantage of them. The
>> language/protocol is named by the service UUID.
>
> Absolutely, it would be like a keyboard being passed as a heart rate monitor. But...
>
>> It's a little like a program that knows how to decode .pngs. If
>> the browser lets the user select a .jpg, the site is just going to have
>> to fail when trying to parse the file.
>
> Yes, exactly: **"the site is going to have to fail"** and not the browser. That's exactly the point: the error and options for recovery should be mediated between the bt device and the script (not by the browser and the user, which is what is currently being proposed). The browser and user are not in a position to make any determination about how the script will communicate with the device - apart from establishing a channel for communication. This is why I said that mixing protocols and the device access request is incorrect - I give a concrete example below.).
>
> Consider:
>
> 1. Script requests device.
> 2. User selects a device (any device).
> 3. UA gives device to script.
> 4. Script interrogates device's supported protocols.
> 5. If the script deems that it can't communicate with the device, it informs the user.
> 6. Script tries to communicate with device: device either talks back or rejects. Script deals with it.
>
>> There's not even much possibility
>> that the device just selected the wrong "extension" in this analogy.
>
> In my mind, this is not really different to:
>
> <input type="file" id="image" accept="image/*">
>
> By default, the UA will say "select an image", but allows the user to select from "All files" - it's up to the script to handle the unsupported format that error (not the browser).
>
> As an analogy, in our case, we are doing:
>
> <input type="device" id="btdevice" accept="bluetooth/heart_rate_monitors/*">
>
> I'm only using the above to illustrate a point, I'm not proposing that we actually use an HTMLInputElement or make some kind of media type thing for bt devices :)
>
>> If the device exposes an unexpected service UUID, but the browser
>> maps that to the expected one (but which of the several exposed UUIDs
>> needs to be mapped?), the website still needs to navigate the
>> characteristics by their UUIDs, which also won't match.
>
> That's totally fine - in fact, that's what you really want because it allows the script to adapt the communication strategy with the BT device (and handle a much larger range of BT devices if it wants). Any rejection is then handled as part of normal error handling in script.
>
> Hope that makes sense.

It does, thanks. I've filed
https://github.com/WebBluetoothCG/web-bluetooth/issues/11 so I don't
forget to write the wording.

What's next? Navigating the Service/Characteristic/Descriptor tree
still uses UUIDs.

Jeffrey

Received on Monday, 11 August 2014 18:27:38 UTC