* [PATCH BlueZ v5] doc/adapter-api.txt: StartFilteredDiscovery method. @ 2015-02-10 0:34 Jakub Pawlowski 2015-02-16 8:46 ` Luiz Augusto von Dentz 0 siblings, 1 reply; 15+ messages in thread From: Jakub Pawlowski @ 2015-02-10 0:34 UTC (permalink / raw) To: linux-bluetooth; +Cc: Jakub Pawlowski This patch proposes new method, StartFilteredDiscovery to D-Bus Adapter API for desktop bluetoothd. It will allow for rapid discovery of nearby devices that advertise services. It also adds FilteredDiscovery property, that is set to true when any StartFilteredDiscovery session is active. Signed-off-by: Jakub Pawlowski <jpawlowski@google.com> --- doc/adapter-api.txt | 49 +++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 49 insertions(+) diff --git a/doc/adapter-api.txt b/doc/adapter-api.txt index 74d235a..b59019d 100644 --- a/doc/adapter-api.txt +++ b/doc/adapter-api.txt @@ -22,6 +22,50 @@ Methods void StartDiscovery() Possible errors: org.bluez.Error.NotReady org.bluez.Error.Failed + void StartFilteredDiscovery(dict filter) + + This method starts the device discovery session with + filtering by uuids, and rssi or pathloss value. Use + StopDiscovery to release the sessions acquired. + + Parameters that can be set in filter dictionary include + the following: + + array{string} UUIDs : filtered service UUIDs (required) + int16 RSSI : RSSI threshold value (optional) + uint16 pathloss : Pathloss threshold value (optional) + string transport: type of scan to run + + When a device is found that advertise any UUID from + UUIDs, it will be reported if: + - pathloss and RSSI are both empty, + - only pathloss param is set, device advertise TX pwer, + and computed pathloss is less than pathloss param, + - only RSSI param is set, and received RSSI is higher + than RSSI param, + + transport parameter determines the type of scan: + "auto" - interleaved scan + "bredr" - br/edr inquiry + "le" - le only scan, default value + + This process will start creating Device objects as new + devices matching criteria are discovered. It will also + emit PropertiesChanged signal for already existing + Device objects, with updated RSSI value. + + StartDiscovery (SD) takes precedence over + StartFilteredDiscovery (SFD). That means that you should + check Discovering property before calling SFD, otherwise + it would fail when any SD session is in progress. + Calling SD when SFD is in progress pause all SFD + sessions, and start them back when all SD sessions are + finished. When filtered discovery state is changed, + FilteredDiscovery variable is updated accordingly. + + Possible errors: org.bluez.Error.NotReady + org.bluez.Error.Failed + void StopDiscovery() This method will cancel any previous StartDiscovery @@ -144,6 +188,11 @@ Properties string Address [readonly] Indicates that a device discovery procedure is active. + boolean FilteredDiscovery [readonly] + + Indicates that a filtered device discovery procedure is + active. + array{string} UUIDs [readonly] List of 128-bit UUIDs that represents the available -- 2.2.0.rc0.207.ga3a616c ^ permalink raw reply related [flat|nested] 15+ messages in thread
* Re: [PATCH BlueZ v5] doc/adapter-api.txt: StartFilteredDiscovery method. 2015-02-10 0:34 [PATCH BlueZ v5] doc/adapter-api.txt: StartFilteredDiscovery method Jakub Pawlowski @ 2015-02-16 8:46 ` Luiz Augusto von Dentz 2015-02-20 17:09 ` Jakub Pawlowski 2015-02-23 13:09 ` Johan Hedberg 0 siblings, 2 replies; 15+ messages in thread From: Luiz Augusto von Dentz @ 2015-02-16 8:46 UTC (permalink / raw) To: Jakub Pawlowski; +Cc: linux-bluetooth, Marcel Holtmann, Johan Hedberg Hi Jakub, On Tue, Feb 10, 2015 at 2:34 AM, Jakub Pawlowski <jpawlowski@google.com> wrote: > This patch proposes new method, StartFilteredDiscovery to D-Bus Adapter > API for desktop bluetoothd. It will allow for rapid discovery of nearby > devices that advertise services. > > It also adds FilteredDiscovery property, that is set to true when any > StartFilteredDiscovery session is active. > > Signed-off-by: Jakub Pawlowski <jpawlowski@google.com> We don't use Signed-off-byin userspace, I can fix this myself this time but please don't sent patches with it anymore. > --- > doc/adapter-api.txt | 49 +++++++++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 49 insertions(+) > > diff --git a/doc/adapter-api.txt b/doc/adapter-api.txt > index 74d235a..b59019d 100644 > --- a/doc/adapter-api.txt > +++ b/doc/adapter-api.txt > @@ -22,6 +22,50 @@ Methods void StartDiscovery() > Possible errors: org.bluez.Error.NotReady > org.bluez.Error.Failed > > + void StartFilteredDiscovery(dict filter) > + > + This method starts the device discovery session with > + filtering by uuids, and rssi or pathloss value. Use > + StopDiscovery to release the sessions acquired. > + > + Parameters that can be set in filter dictionary include > + the following: > + > + array{string} UUIDs : filtered service UUIDs (required) > + int16 RSSI : RSSI threshold value (optional) > + uint16 pathloss : Pathloss threshold value (optional) > + string transport: type of scan to run > + > + When a device is found that advertise any UUID from > + UUIDs, it will be reported if: > + - pathloss and RSSI are both empty, > + - only pathloss param is set, device advertise TX pwer, > + and computed pathloss is less than pathloss param, > + - only RSSI param is set, and received RSSI is higher > + than RSSI param, > + > + transport parameter determines the type of scan: > + "auto" - interleaved scan > + "bredr" - br/edr inquiry > + "le" - le only scan, default value > + > + This process will start creating Device objects as new > + devices matching criteria are discovered. It will also > + emit PropertiesChanged signal for already existing > + Device objects, with updated RSSI value. > + > + StartDiscovery (SD) takes precedence over > + StartFilteredDiscovery (SFD). That means that you should > + check Discovering property before calling SFD, otherwise > + it would fail when any SD session is in progress. > + Calling SD when SFD is in progress pause all SFD > + sessions, and start them back when all SD sessions are > + finished. When filtered discovery state is changed, > + FilteredDiscovery variable is updated accordingly. > + > + Possible errors: org.bluez.Error.NotReady > + org.bluez.Error.Failed > + > void StopDiscovery() > > This method will cancel any previous StartDiscovery > @@ -144,6 +188,11 @@ Properties string Address [readonly] > > Indicates that a device discovery procedure is active. > > + boolean FilteredDiscovery [readonly] > + > + Indicates that a filtered device discovery procedure is > + active. > + > array{string} UUIDs [readonly] > > List of 128-bit UUIDs that represents the available > -- > 2.2.0.rc0.207.ga3a616c @Marcel, Johan: Is this API okay for you? We should probably make them experimental to begin with. -- Luiz Augusto von Dentz ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH BlueZ v5] doc/adapter-api.txt: StartFilteredDiscovery method. 2015-02-16 8:46 ` Luiz Augusto von Dentz @ 2015-02-20 17:09 ` Jakub Pawlowski 2015-02-23 13:09 ` Johan Hedberg 1 sibling, 0 replies; 15+ messages in thread From: Jakub Pawlowski @ 2015-02-20 17:09 UTC (permalink / raw) To: Luiz Augusto von Dentz; +Cc: linux-bluetooth, Marcel Holtmann, Johan Hedberg On Mon, Feb 16, 2015 at 12:46 AM, Luiz Augusto von Dentz <luiz.dentz@gmail.com> wrote: > Hi Jakub, > > On Tue, Feb 10, 2015 at 2:34 AM, Jakub Pawlowski <jpawlowski@google.com> wrote: >> This patch proposes new method, StartFilteredDiscovery to D-Bus Adapter >> API for desktop bluetoothd. It will allow for rapid discovery of nearby >> devices that advertise services. >> >> It also adds FilteredDiscovery property, that is set to true when any >> StartFilteredDiscovery session is active. >> >> Signed-off-by: Jakub Pawlowski <jpawlowski@google.com> > > We don't use Signed-off-byin userspace, I can fix this myself this > time but please don't sent patches with it anymore. Ok, thanks > >> --- >> doc/adapter-api.txt | 49 +++++++++++++++++++++++++++++++++++++++++++++++++ >> 1 file changed, 49 insertions(+) >> >> diff --git a/doc/adapter-api.txt b/doc/adapter-api.txt >> index 74d235a..b59019d 100644 >> --- a/doc/adapter-api.txt >> +++ b/doc/adapter-api.txt >> @@ -22,6 +22,50 @@ Methods void StartDiscovery() >> Possible errors: org.bluez.Error.NotReady >> org.bluez.Error.Failed >> >> + void StartFilteredDiscovery(dict filter) >> + >> + This method starts the device discovery session with >> + filtering by uuids, and rssi or pathloss value. Use >> + StopDiscovery to release the sessions acquired. >> + >> + Parameters that can be set in filter dictionary include >> + the following: >> + >> + array{string} UUIDs : filtered service UUIDs (required) >> + int16 RSSI : RSSI threshold value (optional) >> + uint16 pathloss : Pathloss threshold value (optional) >> + string transport: type of scan to run >> + >> + When a device is found that advertise any UUID from >> + UUIDs, it will be reported if: >> + - pathloss and RSSI are both empty, >> + - only pathloss param is set, device advertise TX pwer, >> + and computed pathloss is less than pathloss param, >> + - only RSSI param is set, and received RSSI is higher >> + than RSSI param, >> + >> + transport parameter determines the type of scan: >> + "auto" - interleaved scan >> + "bredr" - br/edr inquiry >> + "le" - le only scan, default value >> + >> + This process will start creating Device objects as new >> + devices matching criteria are discovered. It will also >> + emit PropertiesChanged signal for already existing >> + Device objects, with updated RSSI value. >> + >> + StartDiscovery (SD) takes precedence over >> + StartFilteredDiscovery (SFD). That means that you should >> + check Discovering property before calling SFD, otherwise >> + it would fail when any SD session is in progress. >> + Calling SD when SFD is in progress pause all SFD >> + sessions, and start them back when all SD sessions are >> + finished. When filtered discovery state is changed, >> + FilteredDiscovery variable is updated accordingly. >> + >> + Possible errors: org.bluez.Error.NotReady >> + org.bluez.Error.Failed >> + >> void StopDiscovery() >> >> This method will cancel any previous StartDiscovery >> @@ -144,6 +188,11 @@ Properties string Address [readonly] >> >> Indicates that a device discovery procedure is active. >> >> + boolean FilteredDiscovery [readonly] >> + >> + Indicates that a filtered device discovery procedure is >> + active. >> + >> array{string} UUIDs [readonly] >> >> List of 128-bit UUIDs that represents the available >> -- >> 2.2.0.rc0.207.ga3a616c > > @Marcel, Johan: Is this API okay for you? We should probably make them > experimental to begin with. Ping ? > > > -- > Luiz Augusto von Dentz ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH BlueZ v5] doc/adapter-api.txt: StartFilteredDiscovery method. 2015-02-16 8:46 ` Luiz Augusto von Dentz 2015-02-20 17:09 ` Jakub Pawlowski @ 2015-02-23 13:09 ` Johan Hedberg 2015-02-23 16:41 ` Jakub Pawlowski 1 sibling, 1 reply; 15+ messages in thread From: Johan Hedberg @ 2015-02-23 13:09 UTC (permalink / raw) To: Luiz Augusto von Dentz; +Cc: Jakub Pawlowski, linux-bluetooth, Marcel Holtmann Hi Luiz, On Mon, Feb 16, 2015, Luiz Augusto von Dentz wrote: > > + void StartFilteredDiscovery(dict filter) > > + > > + This method starts the device discovery session with > > + filtering by uuids, and rssi or pathloss value. Use > > + StopDiscovery to release the sessions acquired. > > + > > + Parameters that can be set in filter dictionary include > > + the following: > > + > > + array{string} UUIDs : filtered service UUIDs (required) > > + int16 RSSI : RSSI threshold value (optional) > > + uint16 pathloss : Pathloss threshold value (optional) > > + string transport: type of scan to run > > + > > + When a device is found that advertise any UUID from > > + UUIDs, it will be reported if: > > + - pathloss and RSSI are both empty, > > + - only pathloss param is set, device advertise TX pwer, > > + and computed pathloss is less than pathloss param, > > + - only RSSI param is set, and received RSSI is higher > > + than RSSI param, > > + > > + transport parameter determines the type of scan: > > + "auto" - interleaved scan > > + "bredr" - br/edr inquiry > > + "le" - le only scan, default value > > + > > + This process will start creating Device objects as new > > + devices matching criteria are discovered. It will also > > + emit PropertiesChanged signal for already existing > > + Device objects, with updated RSSI value. > > + > > + StartDiscovery (SD) takes precedence over > > + StartFilteredDiscovery (SFD). That means that you should > > + check Discovering property before calling SFD, otherwise > > + it would fail when any SD session is in progress. > > + Calling SD when SFD is in progress pause all SFD > > + sessions, and start them back when all SD sessions are > > + finished. When filtered discovery state is changed, > > + FilteredDiscovery variable is updated accordingly. > > + > > + Possible errors: org.bluez.Error.NotReady > > + org.bluez.Error.Failed > > + > > void StopDiscovery() > > > > This method will cancel any previous StartDiscovery > > @@ -144,6 +188,11 @@ Properties string Address [readonly] > > > > Indicates that a device discovery procedure is active. > > > > + boolean FilteredDiscovery [readonly] > > + > > + Indicates that a filtered device discovery procedure is > > + active. > > + > > array{string} UUIDs [readonly] > > > > List of 128-bit UUIDs that represents the available > > -- > > 2.2.0.rc0.207.ga3a616c > > @Marcel, Johan: Is this API okay for you? We should probably make them > experimental to begin with. For the most part I'm fine with this, especially if it's marked as experimental. As for the relationship to StartDiscovery, I'd take a similar approach as we have done with the mgmt API, i.e. StartDiscovery would be just a special kind of filtered discovery without any filters (i.e. reporting all devices). For the case of multiple applications requesting different discoveries at the same time we'd go with the common denominator approach, i.e. applications must be prepared to see devices outside of the range of filters that it has specified (the only way to avoid something like that support is to do unicast D-Bus signals which in turn would break "passive observer" applications). Calling StartDiscovery when there are one or more service discoveries in progress would simply clear out the filters and start reporting all devices. Considering the above style approach, the new property seems a bit pointless. Since we can't any more track multiple different discoveries within the same application (D-Bus connection) the StopDiscovery behavior is now quite broken. The simplest way around that would be to add a discovery instance return parameter to StartServiceDiscovery and to have a new StopServiceDiscovery D-Bus method that'd take this as an input parameter. Johan ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH BlueZ v5] doc/adapter-api.txt: StartFilteredDiscovery method. 2015-02-23 13:09 ` Johan Hedberg @ 2015-02-23 16:41 ` Jakub Pawlowski 2015-02-23 18:43 ` Jakub Pawlowski 2015-02-24 10:37 ` Johan Hedberg 0 siblings, 2 replies; 15+ messages in thread From: Jakub Pawlowski @ 2015-02-23 16:41 UTC (permalink / raw) To: Luiz Augusto von Dentz, Jakub Pawlowski, linux-bluetooth, Marcel Holtmann Hi Johan, Luiz On Mon, Feb 23, 2015 at 5:09 AM, Johan Hedberg <johan.hedberg@gmail.com> wrote: > Hi Luiz, > > On Mon, Feb 16, 2015, Luiz Augusto von Dentz wrote: >> > + void StartFilteredDiscovery(dict filter) >> > + >> > + This method starts the device discovery session with >> > + filtering by uuids, and rssi or pathloss value. Use >> > + StopDiscovery to release the sessions acquired. >> > + >> > + Parameters that can be set in filter dictionary include >> > + the following: >> > + >> > + array{string} UUIDs : filtered service UUIDs (required) >> > + int16 RSSI : RSSI threshold value (optional) >> > + uint16 pathloss : Pathloss threshold value (optional) >> > + string transport: type of scan to run >> > + >> > + When a device is found that advertise any UUID from >> > + UUIDs, it will be reported if: >> > + - pathloss and RSSI are both empty, >> > + - only pathloss param is set, device advertise TX pwer, >> > + and computed pathloss is less than pathloss param, >> > + - only RSSI param is set, and received RSSI is higher >> > + than RSSI param, >> > + >> > + transport parameter determines the type of scan: >> > + "auto" - interleaved scan >> > + "bredr" - br/edr inquiry >> > + "le" - le only scan, default value >> > + >> > + This process will start creating Device objects as new >> > + devices matching criteria are discovered. It will also >> > + emit PropertiesChanged signal for already existing >> > + Device objects, with updated RSSI value. >> > + >> > + StartDiscovery (SD) takes precedence over >> > + StartFilteredDiscovery (SFD). That means that you should >> > + check Discovering property before calling SFD, otherwise >> > + it would fail when any SD session is in progress. >> > + Calling SD when SFD is in progress pause all SFD >> > + sessions, and start them back when all SD sessions are >> > + finished. When filtered discovery state is changed, >> > + FilteredDiscovery variable is updated accordingly. >> > + >> > + Possible errors: org.bluez.Error.NotReady >> > + org.bluez.Error.Failed >> > + >> > void StopDiscovery() >> > >> > This method will cancel any previous StartDiscovery >> > @@ -144,6 +188,11 @@ Properties string Address [readonly] >> > >> > Indicates that a device discovery procedure is active. >> > >> > + boolean FilteredDiscovery [readonly] >> > + >> > + Indicates that a filtered device discovery procedure is >> > + active. >> > + >> > array{string} UUIDs [readonly] >> > >> > List of 128-bit UUIDs that represents the available >> > -- >> > 2.2.0.rc0.207.ga3a616c >> >> @Marcel, Johan: Is this API okay for you? We should probably make them >> experimental to begin with. > > For the most part I'm fine with this, especially if it's marked as > experimental. As for the relationship to StartDiscovery, I'd take a > similar approach as we have done with the mgmt API, i.e. StartDiscovery > would be just a special kind of filtered discovery without any filters > (i.e. reporting all devices). I want StartDiscovery to behave differently than StartFilteredDiscovery without any filter: 1. StartDiscovery is interleaved scan, StartFilteredDiscovery is by default doing LE only scan (BR/EDR doesn't make no point here). If StartFilteredDiscovery would do interleaved scan, it would waste half of time not reporting anything. 2. StartDiscovery is reporting RSSI changes with delta of 8dB or more, StartFilteredDiscovery will report every RSSI change it gets, to allow better proximity approximation. If StartDiscovery report every RSSI change it would break some use cases (i.e. menus showing list of devices would flicker), if StartFilteredDiscovery won't return every RSSI change it would kill my use case. > > For the case of multiple applications requesting different discoveries > at the same time we'd go with the common denominator approach, i.e. > applications must be prepared to see devices outside of the range of > filters that it has specified (the only way to avoid something like that > support is to do unicast D-Bus signals which in turn would break > "passive observer" applications). Calling StartDiscovery when there are > one or more service discoveries in progress would simply clear out the > filters and start reporting all devices. Yes, applications must be prepared to see devices outside of range. When you call StartDiscovery when StartFilteredDiscovery is in progress, filtered discoveries should be paused, and properties should be changed accordingly ("FilteredDiscovery"=false, "Discovering"=true). This would make sure that we don't cause regressions in apps already using StartDiscovery, and new apps that use StartFilteredDiscovery might detect this change by looking at properties, and try to handle it correctly (if they're fine with less frequent RSSI updates, no proximity) or show some message and wait for other apps to stop their discovery. > > Considering the above style approach, the new property seems a bit > pointless. As I mentioned it'll be needed for apps that do StartFilteredDiscovery to check wether it's currently paused to allow other app to do it's StartDiscovery (it takes precedence over StartFilteredDiscovery). > > Since we can't any more track multiple different discoveries within the > same application (D-Bus connection) the StopDiscovery behavior is now > quite broken. The simplest way around that would be to add a discovery > instance return parameter to StartServiceDiscovery and to have a new > StopServiceDiscovery D-Bus method that'd take this as an input > parameter. Right now each application can call StartDiscovery only once, I want each application to be able to call StartDiscovery OR StartFilteredDiscovery only once. This way we are completly fine with one StopDiscovery method. If some application needs to change filter, it can always stop and restart it's scan. > > Johan Jakub ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH BlueZ v5] doc/adapter-api.txt: StartFilteredDiscovery method. 2015-02-23 16:41 ` Jakub Pawlowski @ 2015-02-23 18:43 ` Jakub Pawlowski 2015-02-23 21:43 ` Arman Uguray 2015-02-24 10:37 ` Johan Hedberg 1 sibling, 1 reply; 15+ messages in thread From: Jakub Pawlowski @ 2015-02-23 18:43 UTC (permalink / raw) To: Luiz Augusto von Dentz, Jakub Pawlowski, linux-bluetooth, Marcel Holtmann On Mon, Feb 23, 2015 at 8:41 AM, Jakub Pawlowski <jpawlowski@google.com> wrote: > Hi Johan, Luiz > > On Mon, Feb 23, 2015 at 5:09 AM, Johan Hedberg <johan.hedberg@gmail.com> wrote: >> Hi Luiz, >> >> On Mon, Feb 16, 2015, Luiz Augusto von Dentz wrote: >>> > + void StartFilteredDiscovery(dict filter) >>> > + >>> > + This method starts the device discovery session with >>> > + filtering by uuids, and rssi or pathloss value. Use >>> > + StopDiscovery to release the sessions acquired. >>> > + >>> > + Parameters that can be set in filter dictionary include >>> > + the following: >>> > + >>> > + array{string} UUIDs : filtered service UUIDs (required) >>> > + int16 RSSI : RSSI threshold value (optional) >>> > + uint16 pathloss : Pathloss threshold value (optional) >>> > + string transport: type of scan to run >>> > + >>> > + When a device is found that advertise any UUID from >>> > + UUIDs, it will be reported if: >>> > + - pathloss and RSSI are both empty, >>> > + - only pathloss param is set, device advertise TX pwer, >>> > + and computed pathloss is less than pathloss param, >>> > + - only RSSI param is set, and received RSSI is higher >>> > + than RSSI param, >>> > + >>> > + transport parameter determines the type of scan: >>> > + "auto" - interleaved scan >>> > + "bredr" - br/edr inquiry >>> > + "le" - le only scan, default value >>> > + >>> > + This process will start creating Device objects as new >>> > + devices matching criteria are discovered. It will also >>> > + emit PropertiesChanged signal for already existing >>> > + Device objects, with updated RSSI value. >>> > + >>> > + StartDiscovery (SD) takes precedence over >>> > + StartFilteredDiscovery (SFD). That means that you should >>> > + check Discovering property before calling SFD, otherwise >>> > + it would fail when any SD session is in progress. >>> > + Calling SD when SFD is in progress pause all SFD >>> > + sessions, and start them back when all SD sessions are >>> > + finished. When filtered discovery state is changed, >>> > + FilteredDiscovery variable is updated accordingly. >>> > + >>> > + Possible errors: org.bluez.Error.NotReady >>> > + org.bluez.Error.Failed >>> > + >>> > void StopDiscovery() >>> > >>> > This method will cancel any previous StartDiscovery >>> > @@ -144,6 +188,11 @@ Properties string Address [readonly] >>> > >>> > Indicates that a device discovery procedure is active. >>> > >>> > + boolean FilteredDiscovery [readonly] >>> > + >>> > + Indicates that a filtered device discovery procedure is >>> > + active. >>> > + >>> > array{string} UUIDs [readonly] >>> > >>> > List of 128-bit UUIDs that represents the available >>> > -- >>> > 2.2.0.rc0.207.ga3a616c >>> >>> @Marcel, Johan: Is this API okay for you? We should probably make them >>> experimental to begin with. >> >> For the most part I'm fine with this, especially if it's marked as >> experimental. As for the relationship to StartDiscovery, I'd take a >> similar approach as we have done with the mgmt API, i.e. StartDiscovery >> would be just a special kind of filtered discovery without any filters >> (i.e. reporting all devices). > > I want StartDiscovery to behave differently than > StartFilteredDiscovery without any filter: > 1. StartDiscovery is interleaved scan, StartFilteredDiscovery is by > default doing LE only scan (BR/EDR doesn't make no point here). If > StartFilteredDiscovery would do interleaved scan, it would waste half > of time not reporting anything. > 2. StartDiscovery is reporting RSSI changes with delta of 8dB or more, > StartFilteredDiscovery will report every RSSI change it gets, to allow > better proximity approximation. If StartDiscovery report every RSSI > change it would break some use cases (i.e. menus showing list of > devices would flicker), if StartFilteredDiscovery won't return every > RSSI change it would kill my use case. > > >> >> For the case of multiple applications requesting different discoveries >> at the same time we'd go with the common denominator approach, i.e. >> applications must be prepared to see devices outside of the range of >> filters that it has specified (the only way to avoid something like that >> support is to do unicast D-Bus signals which in turn would break >> "passive observer" applications). Calling StartDiscovery when there are >> one or more service discoveries in progress would simply clear out the >> filters and start reporting all devices. > > Yes, applications must be prepared to see devices outside of range. > When you call StartDiscovery when StartFilteredDiscovery is in > progress, filtered discoveries should be paused, and properties should > be changed accordingly ("FilteredDiscovery"=false, > "Discovering"=true). This would make sure that we don't cause > regressions in apps already using StartDiscovery, and new apps that > use StartFilteredDiscovery might detect this change by looking at > properties, and try to handle it correctly (if they're fine with less > frequent RSSI updates, no proximity) or show some message and wait for > other apps to stop their discovery. > >> >> Considering the above style approach, the new property seems a bit >> pointless. > > As I mentioned it'll be needed for apps that do StartFilteredDiscovery > to check wether it's currently paused to allow other app to do it's > StartDiscovery (it takes precedence over StartFilteredDiscovery). > >> >> Since we can't any more track multiple different discoveries within the >> same application (D-Bus connection) the StopDiscovery behavior is now >> quite broken. The simplest way around that would be to add a discovery >> instance return parameter to StartServiceDiscovery and to have a new >> StopServiceDiscovery D-Bus method that'd take this as an input >> parameter. > > Right now each application can call StartDiscovery only once, I want > each application to be able to call StartDiscovery OR > StartFilteredDiscovery only once. This way we are completly fine with > one StopDiscovery method. If some application needs to change filter, > it can always stop and restart it's scan. It might be good idea to allow multpile StartFilteredDiscovery calls from one client, each replacing the old filter. It would still require only one StopDiscovery method. > >> >> Johan > > Jakub ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH BlueZ v5] doc/adapter-api.txt: StartFilteredDiscovery method. 2015-02-23 18:43 ` Jakub Pawlowski @ 2015-02-23 21:43 ` Arman Uguray 2015-02-23 22:44 ` Jakub Pawlowski 0 siblings, 1 reply; 15+ messages in thread From: Arman Uguray @ 2015-02-23 21:43 UTC (permalink / raw) To: Jakub Pawlowski; +Cc: Luiz Augusto von Dentz, linux-bluetooth, Marcel Holtmann Hi Jakub, Johan, > On Mon, Feb 23, 2015 at 10:43 AM, Jakub Pawlowski <jpawlowski@google.com> wrote: > On Mon, Feb 23, 2015 at 8:41 AM, Jakub Pawlowski <jpawlowski@google.com> wrote: >> Hi Johan, Luiz >> >> On Mon, Feb 23, 2015 at 5:09 AM, Johan Hedberg <johan.hedberg@gmail.com> wrote: >>> Hi Luiz, >>> >>> On Mon, Feb 16, 2015, Luiz Augusto von Dentz wrote: >>>> > + void StartFilteredDiscovery(dict filter) >>>> > + >>>> > + This method starts the device discovery session with >>>> > + filtering by uuids, and rssi or pathloss value. Use >>>> > + StopDiscovery to release the sessions acquired. >>>> > + >>>> > + Parameters that can be set in filter dictionary include >>>> > + the following: >>>> > + >>>> > + array{string} UUIDs : filtered service UUIDs (required) >>>> > + int16 RSSI : RSSI threshold value (optional) >>>> > + uint16 pathloss : Pathloss threshold value (optional) >>>> > + string transport: type of scan to run >>>> > + >>>> > + When a device is found that advertise any UUID from >>>> > + UUIDs, it will be reported if: >>>> > + - pathloss and RSSI are both empty, >>>> > + - only pathloss param is set, device advertise TX pwer, >>>> > + and computed pathloss is less than pathloss param, >>>> > + - only RSSI param is set, and received RSSI is higher >>>> > + than RSSI param, >>>> > + >>>> > + transport parameter determines the type of scan: >>>> > + "auto" - interleaved scan >>>> > + "bredr" - br/edr inquiry >>>> > + "le" - le only scan, default value >>>> > + >>>> > + This process will start creating Device objects as new >>>> > + devices matching criteria are discovered. It will also >>>> > + emit PropertiesChanged signal for already existing >>>> > + Device objects, with updated RSSI value. >>>> > + >>>> > + StartDiscovery (SD) takes precedence over >>>> > + StartFilteredDiscovery (SFD). That means that you should >>>> > + check Discovering property before calling SFD, otherwise >>>> > + it would fail when any SD session is in progress. >>>> > + Calling SD when SFD is in progress pause all SFD >>>> > + sessions, and start them back when all SD sessions are >>>> > + finished. When filtered discovery state is changed, >>>> > + FilteredDiscovery variable is updated accordingly. >>>> > + >>>> > + Possible errors: org.bluez.Error.NotReady >>>> > + org.bluez.Error.Failed >>>> > + >>>> > void StopDiscovery() >>>> > >>>> > This method will cancel any previous StartDiscovery >>>> > @@ -144,6 +188,11 @@ Properties string Address [readonly] >>>> > >>>> > Indicates that a device discovery procedure is active. >>>> > >>>> > + boolean FilteredDiscovery [readonly] >>>> > + >>>> > + Indicates that a filtered device discovery procedure is >>>> > + active. >>>> > + >>>> > array{string} UUIDs [readonly] >>>> > >>>> > List of 128-bit UUIDs that represents the available >>>> > -- >>>> > 2.2.0.rc0.207.ga3a616c >>>> >>>> @Marcel, Johan: Is this API okay for you? We should probably make them >>>> experimental to begin with. >>> >>> For the most part I'm fine with this, especially if it's marked as >>> experimental. As for the relationship to StartDiscovery, I'd take a >>> similar approach as we have done with the mgmt API, i.e. StartDiscovery >>> would be just a special kind of filtered discovery without any filters >>> (i.e. reporting all devices). >> >> I want StartDiscovery to behave differently than >> StartFilteredDiscovery without any filter: >> 1. StartDiscovery is interleaved scan, StartFilteredDiscovery is by >> default doing LE only scan (BR/EDR doesn't make no point here). If >> StartFilteredDiscovery would do interleaved scan, it would waste half >> of time not reporting anything. >> 2. StartDiscovery is reporting RSSI changes with delta of 8dB or more, >> StartFilteredDiscovery will report every RSSI change it gets, to allow >> better proximity approximation. If StartDiscovery report every RSSI >> change it would break some use cases (i.e. menus showing list of >> devices would flicker), if StartFilteredDiscovery won't return every >> RSSI change it would kill my use case. >> >> >>> >>> For the case of multiple applications requesting different discoveries >>> at the same time we'd go with the common denominator approach, i.e. >>> applications must be prepared to see devices outside of the range of >>> filters that it has specified (the only way to avoid something like that >>> support is to do unicast D-Bus signals which in turn would break >>> "passive observer" applications). Calling StartDiscovery when there are >>> one or more service discoveries in progress would simply clear out the >>> filters and start reporting all devices. >> >> Yes, applications must be prepared to see devices outside of range. >> When you call StartDiscovery when StartFilteredDiscovery is in >> progress, filtered discoveries should be paused, and properties should >> be changed accordingly ("FilteredDiscovery"=false, >> "Discovering"=true). This would make sure that we don't cause >> regressions in apps already using StartDiscovery, and new apps that >> use StartFilteredDiscovery might detect this change by looking at >> properties, and try to handle it correctly (if they're fine with less >> frequent RSSI updates, no proximity) or show some message and wait for >> other apps to stop their discovery. >> >>> >>> Considering the above style approach, the new property seems a bit >>> pointless. >> >> As I mentioned it'll be needed for apps that do StartFilteredDiscovery >> to check wether it's currently paused to allow other app to do it's >> StartDiscovery (it takes precedence over StartFilteredDiscovery). >> >>> >>> Since we can't any more track multiple different discoveries within the >>> same application (D-Bus connection) the StopDiscovery behavior is now >>> quite broken. The simplest way around that would be to add a discovery >>> instance return parameter to StartServiceDiscovery and to have a new >>> StopServiceDiscovery D-Bus method that'd take this as an input >>> parameter. >> >> Right now each application can call StartDiscovery only once, I want >> each application to be able to call StartDiscovery OR >> StartFilteredDiscovery only once. This way we are completly fine with >> one StopDiscovery method. If some application needs to change filter, >> it can always stop and restart it's scan. > > It might be good idea to allow multpile StartFilteredDiscovery calls > from one client, each replacing the old filter. It would still require > only one StopDiscovery method. > The 8 dB RSSI argument isn't really valid since this is something that we can change in the API definition. You're saying that interleaved scan is wasteful but that's beside the point here, since the API does allow passing "auto" and "bredr" as the argument and "le" just happens to be the default option. >From an API stand point, I like Johan's suggestion better. Basically we treat all discovery APIs as "filtered" except StartDiscovery is just a special case of StartFilteredDiscovery that has 8 dB as the "RSSI" argument and "auto" for transport. If an app wants to use a lower RSSI threshold then whether or not the UI will flicker should be the responsibility of the UI code. Basically we should treat StartDiscovery as a legacy API and perhaps mark it as deprecated while maintaining support for it for backwards compatibility. Within the new framework, many apps can call StartFilteredDiscovery with differing filters so the daemon should just adapt the filter based on the biggest common denominator. So if I called StartFilteredDiscovery with no UUIDs and someone else calls it with a UUID, the initial call should win. If the first app calls StopDiscovery then we fallback to the second app's filter, etc. >> >>> >>> Johan >> >> Jakub > -- > To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html Arman ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH BlueZ v5] doc/adapter-api.txt: StartFilteredDiscovery method. 2015-02-23 21:43 ` Arman Uguray @ 2015-02-23 22:44 ` Jakub Pawlowski 2015-02-23 23:07 ` Arman Uguray 0 siblings, 1 reply; 15+ messages in thread From: Jakub Pawlowski @ 2015-02-23 22:44 UTC (permalink / raw) To: Arman Uguray; +Cc: Luiz Augusto von Dentz, linux-bluetooth, Marcel Holtmann On Mon, Feb 23, 2015 at 1:43 PM, Arman Uguray <armansito@chromium.org> wrote: > Hi Jakub, Johan, > >> On Mon, Feb 23, 2015 at 10:43 AM, Jakub Pawlowski <jpawlowski@google.com> wrote: >> On Mon, Feb 23, 2015 at 8:41 AM, Jakub Pawlowski <jpawlowski@google.com> wrote: >>> Hi Johan, Luiz >>> >>> On Mon, Feb 23, 2015 at 5:09 AM, Johan Hedberg <johan.hedberg@gmail.com> wrote: >>>> Hi Luiz, >>>> >>>> On Mon, Feb 16, 2015, Luiz Augusto von Dentz wrote: >>>>> > + void StartFilteredDiscovery(dict filter) >>>>> > + >>>>> > + This method starts the device discovery session with >>>>> > + filtering by uuids, and rssi or pathloss value. Use >>>>> > + StopDiscovery to release the sessions acquired. >>>>> > + >>>>> > + Parameters that can be set in filter dictionary include >>>>> > + the following: >>>>> > + >>>>> > + array{string} UUIDs : filtered service UUIDs (required) >>>>> > + int16 RSSI : RSSI threshold value (optional) >>>>> > + uint16 pathloss : Pathloss threshold value (optional) >>>>> > + string transport: type of scan to run >>>>> > + >>>>> > + When a device is found that advertise any UUID from >>>>> > + UUIDs, it will be reported if: >>>>> > + - pathloss and RSSI are both empty, >>>>> > + - only pathloss param is set, device advertise TX pwer, >>>>> > + and computed pathloss is less than pathloss param, >>>>> > + - only RSSI param is set, and received RSSI is higher >>>>> > + than RSSI param, >>>>> > + >>>>> > + transport parameter determines the type of scan: >>>>> > + "auto" - interleaved scan >>>>> > + "bredr" - br/edr inquiry >>>>> > + "le" - le only scan, default value >>>>> > + >>>>> > + This process will start creating Device objects as new >>>>> > + devices matching criteria are discovered. It will also >>>>> > + emit PropertiesChanged signal for already existing >>>>> > + Device objects, with updated RSSI value. >>>>> > + >>>>> > + StartDiscovery (SD) takes precedence over >>>>> > + StartFilteredDiscovery (SFD). That means that you should >>>>> > + check Discovering property before calling SFD, otherwise >>>>> > + it would fail when any SD session is in progress. >>>>> > + Calling SD when SFD is in progress pause all SFD >>>>> > + sessions, and start them back when all SD sessions are >>>>> > + finished. When filtered discovery state is changed, >>>>> > + FilteredDiscovery variable is updated accordingly. >>>>> > + >>>>> > + Possible errors: org.bluez.Error.NotReady >>>>> > + org.bluez.Error.Failed >>>>> > + >>>>> > void StopDiscovery() >>>>> > >>>>> > This method will cancel any previous StartDiscovery >>>>> > @@ -144,6 +188,11 @@ Properties string Address [readonly] >>>>> > >>>>> > Indicates that a device discovery procedure is active. >>>>> > >>>>> > + boolean FilteredDiscovery [readonly] >>>>> > + >>>>> > + Indicates that a filtered device discovery procedure is >>>>> > + active. >>>>> > + >>>>> > array{string} UUIDs [readonly] >>>>> > >>>>> > List of 128-bit UUIDs that represents the available >>>>> > -- >>>>> > 2.2.0.rc0.207.ga3a616c >>>>> >>>>> @Marcel, Johan: Is this API okay for you? We should probably make them >>>>> experimental to begin with. >>>> >>>> For the most part I'm fine with this, especially if it's marked as >>>> experimental. As for the relationship to StartDiscovery, I'd take a >>>> similar approach as we have done with the mgmt API, i.e. StartDiscovery >>>> would be just a special kind of filtered discovery without any filters >>>> (i.e. reporting all devices). >>> >>> I want StartDiscovery to behave differently than >>> StartFilteredDiscovery without any filter: >>> 1. StartDiscovery is interleaved scan, StartFilteredDiscovery is by >>> default doing LE only scan (BR/EDR doesn't make no point here). If >>> StartFilteredDiscovery would do interleaved scan, it would waste half >>> of time not reporting anything. >>> 2. StartDiscovery is reporting RSSI changes with delta of 8dB or more, >>> StartFilteredDiscovery will report every RSSI change it gets, to allow >>> better proximity approximation. If StartDiscovery report every RSSI >>> change it would break some use cases (i.e. menus showing list of >>> devices would flicker), if StartFilteredDiscovery won't return every >>> RSSI change it would kill my use case. >>> >>> >>>> >>>> For the case of multiple applications requesting different discoveries >>>> at the same time we'd go with the common denominator approach, i.e. >>>> applications must be prepared to see devices outside of the range of >>>> filters that it has specified (the only way to avoid something like that >>>> support is to do unicast D-Bus signals which in turn would break >>>> "passive observer" applications). Calling StartDiscovery when there are >>>> one or more service discoveries in progress would simply clear out the >>>> filters and start reporting all devices. >>> >>> Yes, applications must be prepared to see devices outside of range. >>> When you call StartDiscovery when StartFilteredDiscovery is in >>> progress, filtered discoveries should be paused, and properties should >>> be changed accordingly ("FilteredDiscovery"=false, >>> "Discovering"=true). This would make sure that we don't cause >>> regressions in apps already using StartDiscovery, and new apps that >>> use StartFilteredDiscovery might detect this change by looking at >>> properties, and try to handle it correctly (if they're fine with less >>> frequent RSSI updates, no proximity) or show some message and wait for >>> other apps to stop their discovery. >>> >>>> >>>> Considering the above style approach, the new property seems a bit >>>> pointless. >>> >>> As I mentioned it'll be needed for apps that do StartFilteredDiscovery >>> to check wether it's currently paused to allow other app to do it's >>> StartDiscovery (it takes precedence over StartFilteredDiscovery). >>> >>>> >>>> Since we can't any more track multiple different discoveries within the >>>> same application (D-Bus connection) the StopDiscovery behavior is now >>>> quite broken. The simplest way around that would be to add a discovery >>>> instance return parameter to StartServiceDiscovery and to have a new >>>> StopServiceDiscovery D-Bus method that'd take this as an input >>>> parameter. >>> >>> Right now each application can call StartDiscovery only once, I want >>> each application to be able to call StartDiscovery OR >>> StartFilteredDiscovery only once. This way we are completly fine with >>> one StopDiscovery method. If some application needs to change filter, >>> it can always stop and restart it's scan. >> >> It might be good idea to allow multpile StartFilteredDiscovery calls >> from one client, each replacing the old filter. It would still require >> only one StopDiscovery method. >> > > The 8 dB RSSI argument isn't really valid since this is something that > we can change in the API definition. You're saying that interleaved > scan is wasteful but that's beside the point here, since the API does > allow passing "auto" and "bredr" as the argument and "le" just happens > to be the default option. > > From an API stand point, I like Johan's suggestion better. Basically > we treat all discovery APIs as "filtered" except StartDiscovery is > just a special case of StartFilteredDiscovery that has 8 dB as the > "RSSI" argument and "auto" for transport. If an app wants to use a > lower RSSI threshold then whether or not the UI will flicker should be > the responsibility of the UI code. Basically we should treat > StartDiscovery as a legacy API and perhaps mark it as deprecated while > maintaining support for it for backwards compatibility. I think you get the meaning of RSSI parameter wrong. It's not delta, chow much rssi must change to report device again (I think chromeos change that internally to something smaller). It's for proximity - if device reported RSSI is bigger than this RSSI parameter then report it, and there's no delta - we report every RSSI change we get (around 3 times/sec). When it comes to rest of what you write I completly argree. > > Within the new framework, many apps can call StartFilteredDiscovery > with differing filters so the daemon should just adapt the filter > based on the biggest common denominator. So if I called > StartFilteredDiscovery with no UUIDs and someone else calls it with a > UUID, the initial call should win. If the first app calls > StopDiscovery then we fallback to the second app's filter, etc. Yes, version that I have implemented right now can merge filters from multiple clients into one filter that's send to kernel according to rules you mentioned. The question is what should happen when one client call StartFilteredDiscovery multiple times. For StartDiscovery you'd get error. Right now for StartFilteredDiscovery I proposed same thing, However, when I started writing client that uses this new API it's cumbersome to stop and then restart filtered discovery. It would be much more convinient, if for one client calling StartFilteredDiscovery multiple times, it's effective filter is the one from last request (it'll be still merged with filters from other applications). >>> >>>> >>>> Johan >>> >>> Jakub >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in >> the body of a message to majordomo@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html > > Arman Jakub ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH BlueZ v5] doc/adapter-api.txt: StartFilteredDiscovery method. 2015-02-23 22:44 ` Jakub Pawlowski @ 2015-02-23 23:07 ` Arman Uguray 2015-02-24 0:01 ` Jakub Pawlowski 0 siblings, 1 reply; 15+ messages in thread From: Arman Uguray @ 2015-02-23 23:07 UTC (permalink / raw) To: Jakub Pawlowski; +Cc: Luiz Augusto von Dentz, linux-bluetooth, Marcel Holtmann Hi Jakub, > On Mon, Feb 23, 2015 at 2:44 PM, Jakub Pawlowski <jpawlowski@google.com> wrote: > On Mon, Feb 23, 2015 at 1:43 PM, Arman Uguray <armansito@chromium.org> wrote: >> Hi Jakub, Johan, >> >>> On Mon, Feb 23, 2015 at 10:43 AM, Jakub Pawlowski <jpawlowski@google.com> wrote: >>> On Mon, Feb 23, 2015 at 8:41 AM, Jakub Pawlowski <jpawlowski@google.com> wrote: >>>> Hi Johan, Luiz >>>> >>>> On Mon, Feb 23, 2015 at 5:09 AM, Johan Hedberg <johan.hedberg@gmail.com> wrote: >>>>> Hi Luiz, >>>>> >>>>> On Mon, Feb 16, 2015, Luiz Augusto von Dentz wrote: >>>>>> > + void StartFilteredDiscovery(dict filter) >>>>>> > + >>>>>> > + This method starts the device discovery session with >>>>>> > + filtering by uuids, and rssi or pathloss value. Use >>>>>> > + StopDiscovery to release the sessions acquired. >>>>>> > + >>>>>> > + Parameters that can be set in filter dictionary include >>>>>> > + the following: >>>>>> > + >>>>>> > + array{string} UUIDs : filtered service UUIDs (required) >>>>>> > + int16 RSSI : RSSI threshold value (optional) >>>>>> > + uint16 pathloss : Pathloss threshold value (optional) >>>>>> > + string transport: type of scan to run >>>>>> > + >>>>>> > + When a device is found that advertise any UUID from >>>>>> > + UUIDs, it will be reported if: >>>>>> > + - pathloss and RSSI are both empty, >>>>>> > + - only pathloss param is set, device advertise TX pwer, >>>>>> > + and computed pathloss is less than pathloss param, >>>>>> > + - only RSSI param is set, and received RSSI is higher >>>>>> > + than RSSI param, >>>>>> > + >>>>>> > + transport parameter determines the type of scan: >>>>>> > + "auto" - interleaved scan >>>>>> > + "bredr" - br/edr inquiry >>>>>> > + "le" - le only scan, default value >>>>>> > + >>>>>> > + This process will start creating Device objects as new >>>>>> > + devices matching criteria are discovered. It will also >>>>>> > + emit PropertiesChanged signal for already existing >>>>>> > + Device objects, with updated RSSI value. >>>>>> > + >>>>>> > + StartDiscovery (SD) takes precedence over >>>>>> > + StartFilteredDiscovery (SFD). That means that you should >>>>>> > + check Discovering property before calling SFD, otherwise >>>>>> > + it would fail when any SD session is in progress. >>>>>> > + Calling SD when SFD is in progress pause all SFD >>>>>> > + sessions, and start them back when all SD sessions are >>>>>> > + finished. When filtered discovery state is changed, >>>>>> > + FilteredDiscovery variable is updated accordingly. >>>>>> > + >>>>>> > + Possible errors: org.bluez.Error.NotReady >>>>>> > + org.bluez.Error.Failed >>>>>> > + >>>>>> > void StopDiscovery() >>>>>> > >>>>>> > This method will cancel any previous StartDiscovery >>>>>> > @@ -144,6 +188,11 @@ Properties string Address [readonly] >>>>>> > >>>>>> > Indicates that a device discovery procedure is active. >>>>>> > >>>>>> > + boolean FilteredDiscovery [readonly] >>>>>> > + >>>>>> > + Indicates that a filtered device discovery procedure is >>>>>> > + active. >>>>>> > + >>>>>> > array{string} UUIDs [readonly] >>>>>> > >>>>>> > List of 128-bit UUIDs that represents the available >>>>>> > -- >>>>>> > 2.2.0.rc0.207.ga3a616c >>>>>> >>>>>> @Marcel, Johan: Is this API okay for you? We should probably make them >>>>>> experimental to begin with. >>>>> >>>>> For the most part I'm fine with this, especially if it's marked as >>>>> experimental. As for the relationship to StartDiscovery, I'd take a >>>>> similar approach as we have done with the mgmt API, i.e. StartDiscovery >>>>> would be just a special kind of filtered discovery without any filters >>>>> (i.e. reporting all devices). >>>> >>>> I want StartDiscovery to behave differently than >>>> StartFilteredDiscovery without any filter: >>>> 1. StartDiscovery is interleaved scan, StartFilteredDiscovery is by >>>> default doing LE only scan (BR/EDR doesn't make no point here). If >>>> StartFilteredDiscovery would do interleaved scan, it would waste half >>>> of time not reporting anything. >>>> 2. StartDiscovery is reporting RSSI changes with delta of 8dB or more, >>>> StartFilteredDiscovery will report every RSSI change it gets, to allow >>>> better proximity approximation. If StartDiscovery report every RSSI >>>> change it would break some use cases (i.e. menus showing list of >>>> devices would flicker), if StartFilteredDiscovery won't return every >>>> RSSI change it would kill my use case. >>>> >>>> >>>>> >>>>> For the case of multiple applications requesting different discoveries >>>>> at the same time we'd go with the common denominator approach, i.e. >>>>> applications must be prepared to see devices outside of the range of >>>>> filters that it has specified (the only way to avoid something like that >>>>> support is to do unicast D-Bus signals which in turn would break >>>>> "passive observer" applications). Calling StartDiscovery when there are >>>>> one or more service discoveries in progress would simply clear out the >>>>> filters and start reporting all devices. >>>> >>>> Yes, applications must be prepared to see devices outside of range. >>>> When you call StartDiscovery when StartFilteredDiscovery is in >>>> progress, filtered discoveries should be paused, and properties should >>>> be changed accordingly ("FilteredDiscovery"=false, >>>> "Discovering"=true). This would make sure that we don't cause >>>> regressions in apps already using StartDiscovery, and new apps that >>>> use StartFilteredDiscovery might detect this change by looking at >>>> properties, and try to handle it correctly (if they're fine with less >>>> frequent RSSI updates, no proximity) or show some message and wait for >>>> other apps to stop their discovery. >>>> >>>>> >>>>> Considering the above style approach, the new property seems a bit >>>>> pointless. >>>> >>>> As I mentioned it'll be needed for apps that do StartFilteredDiscovery >>>> to check wether it's currently paused to allow other app to do it's >>>> StartDiscovery (it takes precedence over StartFilteredDiscovery). >>>> >>>>> >>>>> Since we can't any more track multiple different discoveries within the >>>>> same application (D-Bus connection) the StopDiscovery behavior is now >>>>> quite broken. The simplest way around that would be to add a discovery >>>>> instance return parameter to StartServiceDiscovery and to have a new >>>>> StopServiceDiscovery D-Bus method that'd take this as an input >>>>> parameter. >>>> >>>> Right now each application can call StartDiscovery only once, I want >>>> each application to be able to call StartDiscovery OR >>>> StartFilteredDiscovery only once. This way we are completly fine with >>>> one StopDiscovery method. If some application needs to change filter, >>>> it can always stop and restart it's scan. >>> >>> It might be good idea to allow multpile StartFilteredDiscovery calls >>> from one client, each replacing the old filter. It would still require >>> only one StopDiscovery method. >>> >> >> The 8 dB RSSI argument isn't really valid since this is something that >> we can change in the API definition. You're saying that interleaved >> scan is wasteful but that's beside the point here, since the API does >> allow passing "auto" and "bredr" as the argument and "le" just happens >> to be the default option. >> >> From an API stand point, I like Johan's suggestion better. Basically >> we treat all discovery APIs as "filtered" except StartDiscovery is >> just a special case of StartFilteredDiscovery that has 8 dB as the >> "RSSI" argument and "auto" for transport. If an app wants to use a >> lower RSSI threshold then whether or not the UI will flicker should be >> the responsibility of the UI code. Basically we should treat >> StartDiscovery as a legacy API and perhaps mark it as deprecated while >> maintaining support for it for backwards compatibility. > > I think you get the meaning of RSSI parameter wrong. It's not delta, > chow much rssi must change to report device again (I think chromeos > change that internally to something smaller). It's for proximity - if > device reported RSSI is bigger than this RSSI parameter then report > it, and there's no delta - we report every RSSI change we get (around > 3 times/sec). > You're right, it's just delta so I was wrong there. Still, the 8 dBm thing shouldn't dictate how the discovery API should work since it only affects what delta threshold to use when updating the Device1.RSSI property. So, perhaps we can add a global D-Bus property for RSSI delta-threshold or perhaps make that a filter parameter of StartFilteredDiscovery. > When it comes to rest of what you write I completly argree. > > >> >> Within the new framework, many apps can call StartFilteredDiscovery >> with differing filters so the daemon should just adapt the filter >> based on the biggest common denominator. So if I called >> StartFilteredDiscovery with no UUIDs and someone else calls it with a >> UUID, the initial call should win. If the first app calls >> StopDiscovery then we fallback to the second app's filter, etc. > > Yes, version that I have implemented right now can merge filters from > multiple clients into one filter that's send to kernel according to > rules you mentioned. > The question is what should happen when one client call > StartFilteredDiscovery multiple times. For StartDiscovery you'd get > error. Right now for StartFilteredDiscovery I proposed same thing, > However, when I started writing client that uses this new API it's > cumbersome to stop and then restart filtered discovery. It would be > much more convinient, if for one client calling StartFilteredDiscovery > multiple times, it's effective filter is the one from last request > (it'll be still merged with filters from other applications). > I don't see why the same application should need to call StartFilteredDiscovery more than once without stopping discovery in between. Then perhaps we need a different API, for instance instead of having a StartFilteredDiscovery maybe we should stick to StartDiscovery and instead add a "SetDiscoveryFilter" method that manages a per-application discovery filter. So if your application needs to reset its filter it can call this method. >>>> >>>>> >>>>> Johan >>>> >>>> Jakub >>> -- >>> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in >>> the body of a message to majordomo@vger.kernel.org >>> More majordomo info at http://vger.kernel.org/majordomo-info.html >> >> Arman > > Jakub Arman ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH BlueZ v5] doc/adapter-api.txt: StartFilteredDiscovery method. 2015-02-23 23:07 ` Arman Uguray @ 2015-02-24 0:01 ` Jakub Pawlowski 2015-02-24 10:51 ` Johan Hedberg 0 siblings, 1 reply; 15+ messages in thread From: Jakub Pawlowski @ 2015-02-24 0:01 UTC (permalink / raw) To: Arman Uguray; +Cc: Luiz Augusto von Dentz, linux-bluetooth, Marcel Holtmann Hi Arman, On Mon, Feb 23, 2015 at 3:07 PM, Arman Uguray <armansito@chromium.org> wrote: > Hi Jakub, > >> On Mon, Feb 23, 2015 at 2:44 PM, Jakub Pawlowski <jpawlowski@google.com> wrote: >> On Mon, Feb 23, 2015 at 1:43 PM, Arman Uguray <armansito@chromium.org> wrote: >>> Hi Jakub, Johan, >>> >>>> On Mon, Feb 23, 2015 at 10:43 AM, Jakub Pawlowski <jpawlowski@google.com> wrote: >>>> On Mon, Feb 23, 2015 at 8:41 AM, Jakub Pawlowski <jpawlowski@google.com> wrote: >>>>> Hi Johan, Luiz >>>>> >>>>> On Mon, Feb 23, 2015 at 5:09 AM, Johan Hedberg <johan.hedberg@gmail.com> wrote: >>>>>> Hi Luiz, >>>>>> >>>>>> On Mon, Feb 16, 2015, Luiz Augusto von Dentz wrote: >>>>>>> > + void StartFilteredDiscovery(dict filter) >>>>>>> > + >>>>>>> > + This method starts the device discovery session with >>>>>>> > + filtering by uuids, and rssi or pathloss value. Use >>>>>>> > + StopDiscovery to release the sessions acquired. >>>>>>> > + >>>>>>> > + Parameters that can be set in filter dictionary include >>>>>>> > + the following: >>>>>>> > + >>>>>>> > + array{string} UUIDs : filtered service UUIDs (required) >>>>>>> > + int16 RSSI : RSSI threshold value (optional) >>>>>>> > + uint16 pathloss : Pathloss threshold value (optional) >>>>>>> > + string transport: type of scan to run >>>>>>> > + >>>>>>> > + When a device is found that advertise any UUID from >>>>>>> > + UUIDs, it will be reported if: >>>>>>> > + - pathloss and RSSI are both empty, >>>>>>> > + - only pathloss param is set, device advertise TX pwer, >>>>>>> > + and computed pathloss is less than pathloss param, >>>>>>> > + - only RSSI param is set, and received RSSI is higher >>>>>>> > + than RSSI param, >>>>>>> > + >>>>>>> > + transport parameter determines the type of scan: >>>>>>> > + "auto" - interleaved scan >>>>>>> > + "bredr" - br/edr inquiry >>>>>>> > + "le" - le only scan, default value >>>>>>> > + >>>>>>> > + This process will start creating Device objects as new >>>>>>> > + devices matching criteria are discovered. It will also >>>>>>> > + emit PropertiesChanged signal for already existing >>>>>>> > + Device objects, with updated RSSI value. >>>>>>> > + >>>>>>> > + StartDiscovery (SD) takes precedence over >>>>>>> > + StartFilteredDiscovery (SFD). That means that you should >>>>>>> > + check Discovering property before calling SFD, otherwise >>>>>>> > + it would fail when any SD session is in progress. >>>>>>> > + Calling SD when SFD is in progress pause all SFD >>>>>>> > + sessions, and start them back when all SD sessions are >>>>>>> > + finished. When filtered discovery state is changed, >>>>>>> > + FilteredDiscovery variable is updated accordingly. >>>>>>> > + >>>>>>> > + Possible errors: org.bluez.Error.NotReady >>>>>>> > + org.bluez.Error.Failed >>>>>>> > + >>>>>>> > void StopDiscovery() >>>>>>> > >>>>>>> > This method will cancel any previous StartDiscovery >>>>>>> > @@ -144,6 +188,11 @@ Properties string Address [readonly] >>>>>>> > >>>>>>> > Indicates that a device discovery procedure is active. >>>>>>> > >>>>>>> > + boolean FilteredDiscovery [readonly] >>>>>>> > + >>>>>>> > + Indicates that a filtered device discovery procedure is >>>>>>> > + active. >>>>>>> > + >>>>>>> > array{string} UUIDs [readonly] >>>>>>> > >>>>>>> > List of 128-bit UUIDs that represents the available >>>>>>> > -- >>>>>>> > 2.2.0.rc0.207.ga3a616c >>>>>>> >>>>>>> @Marcel, Johan: Is this API okay for you? We should probably make them >>>>>>> experimental to begin with. >>>>>> >>>>>> For the most part I'm fine with this, especially if it's marked as >>>>>> experimental. As for the relationship to StartDiscovery, I'd take a >>>>>> similar approach as we have done with the mgmt API, i.e. StartDiscovery >>>>>> would be just a special kind of filtered discovery without any filters >>>>>> (i.e. reporting all devices). >>>>> >>>>> I want StartDiscovery to behave differently than >>>>> StartFilteredDiscovery without any filter: >>>>> 1. StartDiscovery is interleaved scan, StartFilteredDiscovery is by >>>>> default doing LE only scan (BR/EDR doesn't make no point here). If >>>>> StartFilteredDiscovery would do interleaved scan, it would waste half >>>>> of time not reporting anything. >>>>> 2. StartDiscovery is reporting RSSI changes with delta of 8dB or more, >>>>> StartFilteredDiscovery will report every RSSI change it gets, to allow >>>>> better proximity approximation. If StartDiscovery report every RSSI >>>>> change it would break some use cases (i.e. menus showing list of >>>>> devices would flicker), if StartFilteredDiscovery won't return every >>>>> RSSI change it would kill my use case. >>>>> >>>>> >>>>>> >>>>>> For the case of multiple applications requesting different discoveries >>>>>> at the same time we'd go with the common denominator approach, i.e. >>>>>> applications must be prepared to see devices outside of the range of >>>>>> filters that it has specified (the only way to avoid something like that >>>>>> support is to do unicast D-Bus signals which in turn would break >>>>>> "passive observer" applications). Calling StartDiscovery when there are >>>>>> one or more service discoveries in progress would simply clear out the >>>>>> filters and start reporting all devices. >>>>> >>>>> Yes, applications must be prepared to see devices outside of range. >>>>> When you call StartDiscovery when StartFilteredDiscovery is in >>>>> progress, filtered discoveries should be paused, and properties should >>>>> be changed accordingly ("FilteredDiscovery"=false, >>>>> "Discovering"=true). This would make sure that we don't cause >>>>> regressions in apps already using StartDiscovery, and new apps that >>>>> use StartFilteredDiscovery might detect this change by looking at >>>>> properties, and try to handle it correctly (if they're fine with less >>>>> frequent RSSI updates, no proximity) or show some message and wait for >>>>> other apps to stop their discovery. >>>>> >>>>>> >>>>>> Considering the above style approach, the new property seems a bit >>>>>> pointless. >>>>> >>>>> As I mentioned it'll be needed for apps that do StartFilteredDiscovery >>>>> to check wether it's currently paused to allow other app to do it's >>>>> StartDiscovery (it takes precedence over StartFilteredDiscovery). >>>>> >>>>>> >>>>>> Since we can't any more track multiple different discoveries within the >>>>>> same application (D-Bus connection) the StopDiscovery behavior is now >>>>>> quite broken. The simplest way around that would be to add a discovery >>>>>> instance return parameter to StartServiceDiscovery and to have a new >>>>>> StopServiceDiscovery D-Bus method that'd take this as an input >>>>>> parameter. >>>>> >>>>> Right now each application can call StartDiscovery only once, I want >>>>> each application to be able to call StartDiscovery OR >>>>> StartFilteredDiscovery only once. This way we are completly fine with >>>>> one StopDiscovery method. If some application needs to change filter, >>>>> it can always stop and restart it's scan. >>>> >>>> It might be good idea to allow multpile StartFilteredDiscovery calls >>>> from one client, each replacing the old filter. It would still require >>>> only one StopDiscovery method. >>>> >>> >>> The 8 dB RSSI argument isn't really valid since this is something that >>> we can change in the API definition. You're saying that interleaved >>> scan is wasteful but that's beside the point here, since the API does >>> allow passing "auto" and "bredr" as the argument and "le" just happens >>> to be the default option. >>> >>> From an API stand point, I like Johan's suggestion better. Basically >>> we treat all discovery APIs as "filtered" except StartDiscovery is >>> just a special case of StartFilteredDiscovery that has 8 dB as the >>> "RSSI" argument and "auto" for transport. If an app wants to use a >>> lower RSSI threshold then whether or not the UI will flicker should be >>> the responsibility of the UI code. Basically we should treat >>> StartDiscovery as a legacy API and perhaps mark it as deprecated while >>> maintaining support for it for backwards compatibility. >> >> I think you get the meaning of RSSI parameter wrong. It's not delta, >> chow much rssi must change to report device again (I think chromeos >> change that internally to something smaller). It's for proximity - if >> device reported RSSI is bigger than this RSSI parameter then report >> it, and there's no delta - we report every RSSI change we get (around >> 3 times/sec). >> > > You're right, it's just delta so I was wrong there. Still, the 8 dBm > thing shouldn't dictate how the discovery API should work since it > only affects what delta threshold to use when updating the > Device1.RSSI property. So, perhaps we can add a global D-Bus property > for RSSI delta-threshold or perhaps make that a filter parameter of > StartFilteredDiscovery. > If we add global property for changing RSSI delta-threshold we would have to define api to change and probably also negotiate RSSI when multiple apps require different values. Putting it into StartFilteredDiscovery parameter seems more reasonable, but do we really need that ? Can't we just have no RSSI delta for filtered scan, and let apps decide on their own in their logic ? >> When it comes to rest of what you write I completly argree. >> >> >>> >>> Within the new framework, many apps can call StartFilteredDiscovery >>> with differing filters so the daemon should just adapt the filter >>> based on the biggest common denominator. So if I called >>> StartFilteredDiscovery with no UUIDs and someone else calls it with a >>> UUID, the initial call should win. If the first app calls >>> StopDiscovery then we fallback to the second app's filter, etc. >> >> Yes, version that I have implemented right now can merge filters from >> multiple clients into one filter that's send to kernel according to >> rules you mentioned. >> The question is what should happen when one client call >> StartFilteredDiscovery multiple times. For StartDiscovery you'd get >> error. Right now for StartFilteredDiscovery I proposed same thing, >> However, when I started writing client that uses this new API it's >> cumbersome to stop and then restart filtered discovery. It would be >> much more convinient, if for one client calling StartFilteredDiscovery >> multiple times, it's effective filter is the one from last request >> (it'll be still merged with filters from other applications). >> > > I don't see why the same application should need to call > StartFilteredDiscovery more than once without stopping discovery in > between. Then perhaps we need a different API, for instance instead of > having a StartFilteredDiscovery maybe we should stick to > StartDiscovery and instead add a "SetDiscoveryFilter" method that > manages a per-application discovery filter. So if your application > needs to reset its filter it can call this method. Client would call StartFilteredDiscovery when it needs to start filtered discovery, or change it's filter, i.e. add new uuid to it. It can do StopDiscovery and then StartFilteredDiscovery with update filter, but just for convinience I wanted to be able to call StartFilteredDiscovery multiple times. I don't think it's worth splitting it to StartDiscovery and SetDiscoveryFilter. >>>>> >>>>>> >>>>>> Johan >>>>> >>>>> Jakub >>>> -- >>>> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in >>>> the body of a message to majordomo@vger.kernel.org >>>> More majordomo info at http://vger.kernel.org/majordomo-info.html >>> >>> Arman >> >> Jakub > > Arman ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH BlueZ v5] doc/adapter-api.txt: StartFilteredDiscovery method. 2015-02-24 0:01 ` Jakub Pawlowski @ 2015-02-24 10:51 ` Johan Hedberg 0 siblings, 0 replies; 15+ messages in thread From: Johan Hedberg @ 2015-02-24 10:51 UTC (permalink / raw) To: Jakub Pawlowski Cc: Arman Uguray, Luiz Augusto von Dentz, linux-bluetooth, Marcel Holtmann Hi Jakub, On Mon, Feb 23, 2015, Jakub Pawlowski wrote: >>>> From an API stand point, I like Johan's suggestion better. Basically >>>> we treat all discovery APIs as "filtered" except StartDiscovery is >>>> just a special case of StartFilteredDiscovery that has 8 dB as the >>>> "RSSI" argument and "auto" for transport. If an app wants to use a >>>> lower RSSI threshold then whether or not the UI will flicker should be >>>> the responsibility of the UI code. Basically we should treat >>>> StartDiscovery as a legacy API and perhaps mark it as deprecated while >>>> maintaining support for it for backwards compatibility. >>> >>> I think you get the meaning of RSSI parameter wrong. It's not delta, >>> chow much rssi must change to report device again (I think chromeos >>> change that internally to something smaller). It's for proximity - if >>> device reported RSSI is bigger than this RSSI parameter then report >>> it, and there's no delta - we report every RSSI change we get (around >>> 3 times/sec). >> >> You're right, it's just delta so I was wrong there. Still, the 8 dBm >> thing shouldn't dictate how the discovery API should work since it >> only affects what delta threshold to use when updating the >> Device1.RSSI property. So, perhaps we can add a global D-Bus property >> for RSSI delta-threshold or perhaps make that a filter parameter of >> StartFilteredDiscovery. > > If we add global property for changing RSSI delta-threshold we would > have to define api to change and probably also negotiate RSSI when > multiple apps require different values. > Putting it into StartFilteredDiscovery parameter seems more > reasonable, but do we really need that ? > Can't we just have no RSSI delta for filtered scan, and let apps > decide on their own in their logic ? If something like this was exposed through D-Bus then a parameter to StartFilteredDiscovery would be the way to go, I think. However, until we have a clear need for it we can simply keep track of this internally. I.e. StartDiscovery keeps imposing the delta-threshold but as soon as there's one or more StartFilteredDiscovery active this type of filtering is removed. Johan ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH BlueZ v5] doc/adapter-api.txt: StartFilteredDiscovery method. 2015-02-23 16:41 ` Jakub Pawlowski 2015-02-23 18:43 ` Jakub Pawlowski @ 2015-02-24 10:37 ` Johan Hedberg 2015-02-24 20:23 ` Jakub Pawlowski 1 sibling, 1 reply; 15+ messages in thread From: Johan Hedberg @ 2015-02-24 10:37 UTC (permalink / raw) To: Jakub Pawlowski; +Cc: Luiz Augusto von Dentz, linux-bluetooth, Marcel Holtmann Hi Jakub, On Mon, Feb 23, 2015, Jakub Pawlowski wrote: > > Since we can't any more track multiple different discoveries within the > > same application (D-Bus connection) the StopDiscovery behavior is now > > quite broken. The simplest way around that would be to add a discovery > > instance return parameter to StartServiceDiscovery and to have a new > > StopServiceDiscovery D-Bus method that'd take this as an input > > parameter. > > Right now each application can call StartDiscovery only once, I want > each application to be able to call StartDiscovery OR > StartFilteredDiscovery only once. This way we are completly fine with > one StopDiscovery method. If some application needs to change filter, > it can always stop and restart it's scan. Actually I remembered wrong how the current code works. I thought it was allowing multiple StartDiscovery() per app, but there's indeed a hard-coded limit of just one. Keeping this policy around would allow StopDiscovery to be used for StartDiscovery and StartServiceDiscovery alike, and each app would then only be allowed to call one of those at a time. Johan ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH BlueZ v5] doc/adapter-api.txt: StartFilteredDiscovery method. 2015-02-24 10:37 ` Johan Hedberg @ 2015-02-24 20:23 ` Jakub Pawlowski 2015-02-24 22:50 ` Marcel Holtmann 0 siblings, 1 reply; 15+ messages in thread From: Jakub Pawlowski @ 2015-02-24 20:23 UTC (permalink / raw) To: Jakub Pawlowski, Luiz Augusto von Dentz, linux-bluetooth, Marcel Holtmann, Arman Uguray Hi Johan, On Tue, Feb 24, 2015 at 2:37 AM, Johan Hedberg <johan.hedberg@gmail.com> wrote: > Hi Jakub, > > On Mon, Feb 23, 2015, Jakub Pawlowski wrote: >> > Since we can't any more track multiple different discoveries within the >> > same application (D-Bus connection) the StopDiscovery behavior is now >> > quite broken. The simplest way around that would be to add a discovery >> > instance return parameter to StartServiceDiscovery and to have a new >> > StopServiceDiscovery D-Bus method that'd take this as an input >> > parameter. >> >> Right now each application can call StartDiscovery only once, I want >> each application to be able to call StartDiscovery OR >> StartFilteredDiscovery only once. This way we are completly fine with >> one StopDiscovery method. If some application needs to change filter, >> it can always stop and restart it's scan. > > Actually I remembered wrong how the current code works. I thought it was > allowing multiple StartDiscovery() per app, but there's indeed a > hard-coded limit of just one. Keeping this policy around would allow > StopDiscovery to be used for StartDiscovery and StartServiceDiscovery > alike, and each app would then only be allowed to call one of those at a > time. > So I want to keep the limit of one session per app, but I think that app should be able to call StartServiceDiscovery multiple times, in order to update it's filter without calling StopDiscovery to first stop it's discovery. That would simplify filter updating for apps that would have such need, and make their logic simpler. Example: App wants to update it's filter. If It can't call StartServiceDiscovery more than once, here are steps: 1. app call StopDiscovery. 2. Discovering property changed to false. 3. It calls StartFilteredDiscovery with updated filter. 4. Discovering property changed to true If calling StartFilteredDiscovery more than once is possible: 1. app call StartServiceDiscovery with updated filter, filter is updated internally and "Discovering" property is not updated at all. I think I argree with all other comments from other emails. I'll update documentation accordingly. I'll say in doc, that StartServiceDiscovery might be called multiple times, and keep only one session. If anyone doesn't argree with that I'll remove that, as that's only for convinience, and doesn't really affect functionality. > Johan ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH BlueZ v5] doc/adapter-api.txt: StartFilteredDiscovery method. 2015-02-24 20:23 ` Jakub Pawlowski @ 2015-02-24 22:50 ` Marcel Holtmann 2015-02-24 23:12 ` Jakub Pawlowski 0 siblings, 1 reply; 15+ messages in thread From: Marcel Holtmann @ 2015-02-24 22:50 UTC (permalink / raw) To: Jakub Pawlowski; +Cc: Luiz Augusto von Dentz, linux-bluetooth, Arman Uguray Hi Jakub, >>>> Since we can't any more track multiple different discoveries within the >>>> same application (D-Bus connection) the StopDiscovery behavior is now >>>> quite broken. The simplest way around that would be to add a discovery >>>> instance return parameter to StartServiceDiscovery and to have a new >>>> StopServiceDiscovery D-Bus method that'd take this as an input >>>> parameter. >>> >>> Right now each application can call StartDiscovery only once, I want >>> each application to be able to call StartDiscovery OR >>> StartFilteredDiscovery only once. This way we are completly fine with >>> one StopDiscovery method. If some application needs to change filter, >>> it can always stop and restart it's scan. >> >> Actually I remembered wrong how the current code works. I thought it was >> allowing multiple StartDiscovery() per app, but there's indeed a >> hard-coded limit of just one. Keeping this policy around would allow >> StopDiscovery to be used for StartDiscovery and StartServiceDiscovery >> alike, and each app would then only be allowed to call one of those at a >> time. >> > > So I want to keep the limit of one session per app, but I think that > app should be able to call StartServiceDiscovery multiple times, in > order to update it's filter without calling StopDiscovery to first > stop it's discovery. That would simplify filter updating for apps that > would have such need, and make their logic simpler. we have never done such an API design before. I am a bit reluctant to allow that now. The whole API design is falling into one simple approach that the name of method calls and properties is pretty self explanatory. That StartServiceDiscovery means also additionally UpdateServiceDiscovery is not something I would consider intuitive. > Example: App wants to update it's filter. If It can't call > StartServiceDiscovery more than once, here are steps: > 1. app call StopDiscovery. > 2. Discovering property changed to false. > 3. It calls StartFilteredDiscovery with updated filter. > 4. Discovering property changed to true > > If calling StartFilteredDiscovery more than once is possible: > 1. app call StartServiceDiscovery with updated filter, filter is > updated internally and "Discovering" property is not updated at all. > > > I think I argree with all other comments from other emails. I'll > update documentation accordingly. > I'll say in doc, that StartServiceDiscovery might be called multiple > times, and keep only one session. If anyone doesn't argree with that > I'll remove that, as that's only for convinience, and doesn't really > affect functionality. While I just looked at this for only a few minutes, the double execution of StartServiceDiscovery is something that does not fell right. Why not introduce UpdateServiceDiscovery or ChangeServiceDiscovery. Regards Marcel ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH BlueZ v5] doc/adapter-api.txt: StartFilteredDiscovery method. 2015-02-24 22:50 ` Marcel Holtmann @ 2015-02-24 23:12 ` Jakub Pawlowski 0 siblings, 0 replies; 15+ messages in thread From: Jakub Pawlowski @ 2015-02-24 23:12 UTC (permalink / raw) To: Marcel Holtmann; +Cc: Luiz Augusto von Dentz, linux-bluetooth, Arman Uguray On Tue, Feb 24, 2015 at 2:50 PM, Marcel Holtmann <marcel@holtmann.org> wrot= e: > Hi Jakub, > >>>>> Since we can't any more track multiple different discoveries within t= he >>>>> same application (D-Bus connection) the StopDiscovery behavior is now >>>>> quite broken. The simplest way around that would be to add a discover= y >>>>> instance return parameter to StartServiceDiscovery and to have a new >>>>> StopServiceDiscovery D-Bus method that'd take this as an input >>>>> parameter. >>>> >>>> Right now each application can call StartDiscovery only once, I want >>>> each application to be able to call StartDiscovery OR >>>> StartFilteredDiscovery only once. This way we are completly fine with >>>> one StopDiscovery method. If some application needs to change filter, >>>> it can always stop and restart it's scan. >>> >>> Actually I remembered wrong how the current code works. I thought it wa= s >>> allowing multiple StartDiscovery() per app, but there's indeed a >>> hard-coded limit of just one. Keeping this policy around would allow >>> StopDiscovery to be used for StartDiscovery and StartServiceDiscovery >>> alike, and each app would then only be allowed to call one of those at = a >>> time. >>> >> >> So I want to keep the limit of one session per app, but I think that >> app should be able to call StartServiceDiscovery multiple times, in >> order to update it's filter without calling StopDiscovery to first >> stop it's discovery. That would simplify filter updating for apps that >> would have such need, and make their logic simpler. > > we have never done such an API design before. I am a bit reluctant to all= ow that now. The whole API design is falling into one simple approach that = the name of method calls and properties is pretty self explanatory. That St= artServiceDiscovery means also additionally UpdateServiceDiscovery is not s= omething I would consider intuitive. > >> Example: App wants to update it's filter. If It can't call >> StartServiceDiscovery more than once, here are steps: >> 1. app call StopDiscovery. >> 2. Discovering property changed to false. >> 3. It calls StartFilteredDiscovery with updated filter. >> 4. Discovering property changed to true >> >> If calling StartFilteredDiscovery more than once is possible: >> 1. app call StartServiceDiscovery with updated filter, filter is >> updated internally and "Discovering" property is not updated at all. >> >> >> I think I argree with all other comments from other emails. I'll >> update documentation accordingly. >> I'll say in doc, that StartServiceDiscovery might be called multiple >> times, and keep only one session. If anyone doesn't argree with that >> I'll remove that, as that's only for convinience, and doesn't really >> affect functionality. > > While I just looked at this for only a few minutes, the double execution = of StartServiceDiscovery is something that does not fell right. Why not int= roduce UpdateServiceDiscovery or ChangeServiceDiscovery. Ok, I'll make it so you can call StartFilteredDiscovery only once. If you want to change filter just stop and start the filtered scan again. > > Regards > > Marcel > ^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2015-02-24 23:12 UTC | newest] Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2015-02-10 0:34 [PATCH BlueZ v5] doc/adapter-api.txt: StartFilteredDiscovery method Jakub Pawlowski 2015-02-16 8:46 ` Luiz Augusto von Dentz 2015-02-20 17:09 ` Jakub Pawlowski 2015-02-23 13:09 ` Johan Hedberg 2015-02-23 16:41 ` Jakub Pawlowski 2015-02-23 18:43 ` Jakub Pawlowski 2015-02-23 21:43 ` Arman Uguray 2015-02-23 22:44 ` Jakub Pawlowski 2015-02-23 23:07 ` Arman Uguray 2015-02-24 0:01 ` Jakub Pawlowski 2015-02-24 10:51 ` Johan Hedberg 2015-02-24 10:37 ` Johan Hedberg 2015-02-24 20:23 ` Jakub Pawlowski 2015-02-24 22:50 ` Marcel Holtmann 2015-02-24 23:12 ` Jakub Pawlowski
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.