[RFC BlueZ] Proximity API simplification

[RFC BlueZ] Proximity API simplification

[Claudio Takahasi]

Delegates the Immediate Alert Level control to the caller(client).
Immediate Alert Service is shared between Path Loss and Find Me.

Cons: distributed actions may impact qualification. Client needs to
control when to write the Immediate Alert based on the received
SignalLevel received.
---

 I'd like to collect feedbacks before proceeding with this change.
 Does it look more clear than the previous API version?

 The ideia is to move to the kernel the RSSI value polling. The
 userspace will receive notifications when one of the SignalLevel
 threshold is triggered: "good", "regular", "week".

 Regards,
 Claudio

 doc/proximity-api.txt |   36 ++++++------------------------------
 1 files changed, 6 insertions(+), 30 deletions(-)

diff --git a/doc/proximity-api.txt b/doc/proximity-api.txt
index ed78fb5..cf64bbf 100644
--- a/doc/proximity-api.txt
+++ b/doc/proximity-api.txt
@@ -30,29 +30,11 @@ Signals		PropertyChanged(string name, variant value)
 			property.
 
 Properties
-		uint8 PathLoss[readonly]
 
-			If Tx Power Service is available, this property value
-			will be reported on regular intervals when the peer is
-			connected. Range: 0 - 100. The number is a relative
-			value to represent inaccurately the signal strength,
-			where 0 represents out of range and 100 close to the
-			reporter.
+		string SignalLevel[readonly]
 
-		string Threshold [readwrite]
-
-			Persistent property. Trigger for immediate alert.
-			Values: "low", "medium", "high". Enabled only if Tx
-			Power and Immediate Alert services are available in
-			the reporter. Controls when the immediate alert is
-			triggered in the reporter.
-
-		boolean ThresholdAlert[readonly]
-
-			Alert indicating that threshold has been reached or the
-			path loss returned to a value below the threshold. It is
-			up to the implementation catch this property value and
-			emit a sound in the proximity monitor.
+			Alert indicating that a threshold has been reached.
+			Possible values: "unknown", "good", "regular", "weak"
 
 		string LinkLossAlertLevel [readwrite]
 
@@ -60,16 +42,10 @@ Properties
 			proximity reporter for link loss scenario. Values:
 			"none", "mild", "high".
 
-		string PathLossAlertLevel [readwrite]
-
-			Persistent property. Alert level for path loss scenario.
-			It's a LOCAL property value written in the Alert Level of
-			the Immediate Alert service when the threshold alert is
-			triggered. Values: "none", "mild", "high".
-
-		string FindMeAlertLevel [readwrite]
+		string ImmediateAlertLevel [readwrite]
 
-			Alert level to be written in the Find Me Target.
+			Alert level to be written in the Immediate Alert Level.
+			Property shared between Path Loss and Find Me.
 			Values: "none", "mild", "high". Default value is
 			"none". Applications can disable the alert setting
 			the value to "none". If the "Target" is not found,
-- 
1.7.6

Re: [RFC BlueZ] Proximity API simplification

[Anderson Briglia]

Hi Claudio,

On Mon, Jul 18, 2011 at 2:35 PM, Claudio Takahasi
<claudio.takahasi@openbossa.org> wrote:
> Delegates the Immediate Alert Level control to the caller(client).
> Immediate Alert Service is shared between Path Loss and Find Me.
>
> Cons: distributed actions may impact qualification. Client needs to
> control when to write the Immediate Alert based on the received
> SignalLevel received.
> ---
>
>  I'd like to collect feedbacks before proceeding with this change.
>  Does it look more clear than the previous API version?
>
>  The ideia is to move to the kernel the RSSI value polling. The
>  userspace will receive notifications when one of the SignalLevel
>  threshold is triggered: "good", "regular", "week".

How about simplify more and have just two alert levels? Is there any
reason to have three? It could simplify the RSSI Monitor in the
kernel.

Regards,

Anderson Briglia

>
>  Regards,
>  Claudio
>
>  doc/proximity-api.txt |   36 ++++++------------------------------
>  1 files changed, 6 insertions(+), 30 deletions(-)
>
> diff --git a/doc/proximity-api.txt b/doc/proximity-api.txt
> index ed78fb5..cf64bbf 100644
> --- a/doc/proximity-api.txt
> +++ b/doc/proximity-api.txt
> @@ -30,29 +30,11 @@ Signals             PropertyChanged(string name, variant value)
>                        property.
>
>  Properties
> -               uint8 PathLoss[readonly]
>
> -                       If Tx Power Service is available, this property value
> -                       will be reported on regular intervals when the peer is
> -                       connected. Range: 0 - 100. The number is a relative
> -                       value to represent inaccurately the signal strength,
> -                       where 0 represents out of range and 100 close to the
> -                       reporter.
> +               string SignalLevel[readonly]
>
> -               string Threshold [readwrite]
> -
> -                       Persistent property. Trigger for immediate alert.
> -                       Values: "low", "medium", "high". Enabled only if Tx
> -                       Power and Immediate Alert services are available in
> -                       the reporter. Controls when the immediate alert is
> -                       triggered in the reporter.
> -
> -               boolean ThresholdAlert[readonly]
> -
> -                       Alert indicating that threshold has been reached or the
> -                       path loss returned to a value below the threshold. It is
> -                       up to the implementation catch this property value and
> -                       emit a sound in the proximity monitor.
> +                       Alert indicating that a threshold has been reached.
> +                       Possible values: "unknown", "good", "regular", "weak"
>
>                string LinkLossAlertLevel [readwrite]
>
> @@ -60,16 +42,10 @@ Properties
>                        proximity reporter for link loss scenario. Values:
>                        "none", "mild", "high".
>
> -               string PathLossAlertLevel [readwrite]
> -
> -                       Persistent property. Alert level for path loss scenario.
> -                       It's a LOCAL property value written in the Alert Level of
> -                       the Immediate Alert service when the threshold alert is
> -                       triggered. Values: "none", "mild", "high".
> -
> -               string FindMeAlertLevel [readwrite]
> +               string ImmediateAlertLevel [readwrite]
>
> -                       Alert level to be written in the Find Me Target.
> +                       Alert level to be written in the Immediate Alert Level.
> +                       Property shared between Path Loss and Find Me.
>                        Values: "none", "mild", "high". Default value is
>                        "none". Applications can disable the alert setting
>                        the value to "none". If the "Target" is not found,
> --
> 1.7.6
>
> --
> 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
>



-- 
INdT - Instituto Nokia de tecnologia
+55 92 2126 1122
+55 92 8423 3183

Re: [RFC BlueZ] Proximity API simplification

[Claudio Takahasi]

Hi Briglia,

On Tue, Jul 19, 2011 at 11:34 AM, Anderson Briglia
<anderson.briglia@openbossa.org> wrote:
> Hi Claudio,
>
> On Mon, Jul 18, 2011 at 2:35 PM, Claudio Takahasi
> <claudio.takahasi@openbossa.org> wrote:
>> Delegates the Immediate Alert Level control to the caller(client).
>> Immediate Alert Service is shared between Path Loss and Find Me.
>>
>> Cons: distributed actions may impact qualification. Client needs to
>> control when to write the Immediate Alert based on the received
>> SignalLevel received.
>> ---
>>
>>  I'd like to collect feedbacks before proceeding with this change.
>>  Does it look more clear than the previous API version?
>>
>>  The ideia is to move to the kernel the RSSI value polling. The
>>  userspace will receive notifications when one of the SignalLevel
>>  threshold is triggered: "good", "regular", "week".
>
> How about simplify more and have just two alert levels? Is there any
> reason to have three? It could simplify the RSSI Monitor in the
> kernel.
>
> Regards,
>
> Anderson Briglia

Choosing two levels only, clients will not be able to map directly the
3 alert levels values of the Immediate Alert Characteristic: none,
mild, high.
My suggestion is to implement the following mapping:
good->none
regular->mild
weak->high

Of course, based on the proposal of delegating the write
operation(SetProperty) to the client, it up to the client to choose
when and which alert level to use.
Clients could also consider the selected phone profile(eg: silent,
meeting, normal) also to choose the alert level.

Resuming, I don't have a strong argument to have 3 levels, I defined 3
to simplify the mapping of immediate alert level characteristic. But
this is implementation specific.

Regards,
Claudio.

Re: [RFC BlueZ] Proximity API simplification

[Claudio Takahasi]

Hi Briglia,

On Tue, Jul 19, 2011 at 12:11 PM, Claudio Takahasi
<claudio.takahasi@openbossa.org> wrote:
> Hi Briglia,
>
> On Tue, Jul 19, 2011 at 11:34 AM, Anderson Briglia
> <anderson.briglia@openbossa.org> wrote:
>> Hi Claudio,
>>
>> On Mon, Jul 18, 2011 at 2:35 PM, Claudio Takahasi
>> <claudio.takahasi@openbossa.org> wrote:
>>> Delegates the Immediate Alert Level control to the caller(client).
>>> Immediate Alert Service is shared between Path Loss and Find Me.
>>>
>>> Cons: distributed actions may impact qualification. Client needs to
>>> control when to write the Immediate Alert based on the received
>>> SignalLevel received.
>>> ---
>>>
>>>  I'd like to collect feedbacks before proceeding with this change.
>>>  Does it look more clear than the previous API version?
>>>
>>>  The ideia is to move to the kernel the RSSI value polling. The
>>>  userspace will receive notifications when one of the SignalLevel
>>>  threshold is triggered: "good", "regular", "week".
>>
>> How about simplify more and have just two alert levels? Is there any
>> reason to have three? It could simplify the RSSI Monitor in the
>> kernel.
>>
>> Regards,
>>
>> Anderson Briglia
>
> Choosing two levels only, clients will not be able to map directly the
> 3 alert levels values of the Immediate Alert Characteristic: none,
> mild, high.
> My suggestion is to implement the following mapping:
> good->none
> regular->mild
> weak->high
>
> Of course, based on the proposal of delegating the write
> operation(SetProperty) to the client, it up to the client to choose
> when and which alert level to use.
> Clients could also consider the selected phone profile(eg: silent,
> meeting, normal) also to choose the alert level.
>
> Resuming, I don't have a strong argument to have 3 levels, I defined 3
> to simplify the mapping of immediate alert level characteristic. But
> this is implementation specific.
>
> Regards,
> Claudio.
>

We had a small misunderstanding about thresholds and alerts. 2
thresholds should be mapped into 3 states/intervals. The changes that
I proposed is aligned with your RSSI monitor(in the kernel) proposal.
Please send the Management API RFC.

SignalLevel in the Proximity API doesn't need to be mapped directly in
the RSSI monitor states, we are aligning it to expose to the clients
all transitions.


Regards,
Claudio

[PATCH BlueZ] Proximity API simplification

[Claudio Takahasi]

Delegates the Immediate Alert Level control to the caller(client).
Immediate Alert Service is shared between Path Loss and Find Me.

Three signal level states are defined: "good", "regular" and "weak".
Meaning that at least two thresholds are necessary to implement a
proper state transition. "unknown" will be returned if the link is not
active. For Path Loss, the logic to trigger the writting operation of
the Immediate Alert Level characteristic needs to be implemented in
the client. SignalLevel can be only one of the inputs to define when
and which value to write in the characteristic.
---
 doc/proximity-api.txt |   36 ++++++------------------------------
 1 files changed, 6 insertions(+), 30 deletions(-)

diff --git a/doc/proximity-api.txt b/doc/proximity-api.txt
index ed78fb5..cf64bbf 100644
--- a/doc/proximity-api.txt
+++ b/doc/proximity-api.txt
@@ -30,29 +30,11 @@ Signals		PropertyChanged(string name, variant value)
 			property.
 
 Properties
-		uint8 PathLoss[readonly]
 
-			If Tx Power Service is available, this property value
-			will be reported on regular intervals when the peer is
-			connected. Range: 0 - 100. The number is a relative
-			value to represent inaccurately the signal strength,
-			where 0 represents out of range and 100 close to the
-			reporter.
+		string SignalLevel[readonly]
 
-		string Threshold [readwrite]
-
-			Persistent property. Trigger for immediate alert.
-			Values: "low", "medium", "high". Enabled only if Tx
-			Power and Immediate Alert services are available in
-			the reporter. Controls when the immediate alert is
-			triggered in the reporter.
-
-		boolean ThresholdAlert[readonly]
-
-			Alert indicating that threshold has been reached or the
-			path loss returned to a value below the threshold. It is
-			up to the implementation catch this property value and
-			emit a sound in the proximity monitor.
+			Alert indicating that a threshold has been reached.
+			Possible values: "unknown", "good", "regular", "weak"
 
 		string LinkLossAlertLevel [readwrite]
 
@@ -60,16 +42,10 @@ Properties
 			proximity reporter for link loss scenario. Values:
 			"none", "mild", "high".
 
-		string PathLossAlertLevel [readwrite]
-
-			Persistent property. Alert level for path loss scenario.
-			It's a LOCAL property value written in the Alert Level of
-			the Immediate Alert service when the threshold alert is
-			triggered. Values: "none", "mild", "high".
-
-		string FindMeAlertLevel [readwrite]
+		string ImmediateAlertLevel [readwrite]
 
-			Alert level to be written in the Find Me Target.
+			Alert level to be written in the Immediate Alert Level.
+			Property shared between Path Loss and Find Me.
 			Values: "none", "mild", "high". Default value is
 			"none". Applications can disable the alert setting
 			the value to "none". If the "Target" is not found,
-- 
1.7.6

Re: [PATCH BlueZ] Proximity API simplification

[Johan Hedberg]

Hi Claudio,

On Tue, Jul 19, 2011, Claudio Takahasi wrote:
> Delegates the Immediate Alert Level control to the caller(client).
> Immediate Alert Service is shared between Path Loss and Find Me.
> 
> Three signal level states are defined: "good", "regular" and "weak".
> Meaning that at least two thresholds are necessary to implement a
> proper state transition. "unknown" will be returned if the link is not
> active. For Path Loss, the logic to trigger the writting operation of
> the Immediate Alert Level characteristic needs to be implemented in
> the client. SignalLevel can be only one of the inputs to define when
> and which value to write in the characteristic.
> ---
>  doc/proximity-api.txt |   36 ++++++------------------------------
>  1 files changed, 6 insertions(+), 30 deletions(-)

Applied. Thanks.

Johan