- 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
@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