W3C home > Mailing lists > Public > public-web-bluetooth-log@w3.org > May 2016

Re: [web-bluetooth] Allow requestDevice for all devices

From: Jeffrey Yasskin via GitHub <sysbot+gh@w3.org>
Date: Fri, 13 May 2016 17:25:26 +0000
To: public-web-bluetooth-log@w3.org
Message-ID: <issue_comment.created-219106840-1463160325-sysbot+gh@w3.org>
@nemik Your question is #153: yes, I think it makes sense to filter by
 manufacturer data and service data.

@youcangetme If you have a concrete use case that we're not 
supporting, could you file another issue? Everything your comment 
mentions can be done with the existing filters. e.g. [filtering by 
known 
names](https://webbluetoothcg.github.io/web-bluetooth/#dictdef-bluetoothrequestdevicefilter).

@scheib I'm torn: on the one hand, I think most uses of this API will 
be for applications that need to talk to particular devices that can 
be identified by their advertisements. It's only the generic utilities
 that need to look at arbitrary devices, and those are likely served 
better by native apps anyway, so they're not constrained by the web's 
permission restrictions. However, to popularize the API, maybe we do 
want to implement some generic utilities like the [rename 
tool](https://rawgit.com/scheib/webbluetoothcg-demos/bluetooth-rename/bluetooth-rename/index.html)
 and @beaufortfrancois' [GAP 
reader](https://github.com/GoogleChrome/samples/pull/337).

We could allow folks to list `'generic_access'` and 
`'generic_attribute'` in their services filter and infer that all 
devices match that even though they don't explicitly advertise it. I'm
 inclined to put some restriction on those requests, for example that 
they can't have other filters or list any optional services, but I'm 
not sure that's the best idea. Maybe just a scary key is the way to 
go.

-- 
GitHub Notification of comment by jyasskin
Please view or discuss this issue at 
https://github.com/WebBluetoothCG/web-bluetooth/issues/234#issuecomment-219106840
 using your GitHub account
Received on Friday, 13 May 2016 17:25:27 UTC

This archive was generated by hypermail 2.3.1 : Friday, 13 May 2016 17:25:28 UTC