- From: Nik Markovic via GitHub <sysbot+gh@w3.org>
- Date: Thu, 28 Jul 2016 19:22:15 +0000
- To: public-web-bluetooth-log@w3.org
>> 3) Shouldn't typical scan filters be applicable to this scan? For example, matching on a name. > I think the name and namePrefix filters are the only ones I have in requestDevice() but not requestLEScan(). Android provides an exact name match, but not a partial name match, which limits the efficiency gains we can get by specifying a partial match. (Of course, iOS has much weaker filters.) My impression of requestDevice() uses is that most have needed to use partial name matches. > So, I'm inclined not to include name filters in requestLEScan() until we find concrete use cases. Isn't it implicit that requestLEScan filters are implemendted in software (browser) anyways? That way we are not limited to what the underlying bluetooth API implements. requestDevice is implemented in software, right? If we implement it in software, then we can have multiple sessions doing scans and filters of their own irrespective of what the adapter/native is filtering. Also, iOS and BluZ only supports limited filtering options, which typically include only service UUID and/or a couple of other minor things. How do we deal with that then? If this filter gets implemented in software, it seems to gravitate towards making filtering options and algorithm the same for both requestDevice and requestLEScan. -- GitHub Notification of comment by nik-markovic Please view or discuss this issue at https://github.com/WebBluetoothCG/web-bluetooth/pull/239#issuecomment-235998032 using your GitHub account
Received on Thursday, 28 July 2016 19:22:22 UTC